[PATCH 1/3] drm/radeon: Clean up reference counting and pinning of the cursor BOs

[Grigori Goronzy]

On 2015-07-07 09:27, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> Take a GEM reference for and pin the new cursor BO, unpin and drop the
> GEM reference for the old cursor BO in radeon_crtc_cursor_set2, and use
> radeon_crtc->cursor_addr in radeon_set_cursor.
> 
> This fixes radeon_cursor_reset accidentally incrementing the cursor BO
> pin count, and cleans up the code a little.
> 

Thank you for finishing this up!

Series is
Reviewed-by: Grigori Goronzy 

> Cc: stable at vger.kernel.org
> Signed-off-by: Michel Dänzer 
> ---
>  drivers/gpu/drm/radeon/radeon_cursor.c | 84 
> +++---
>  drivers/gpu/drm/radeon/radeon_mode.h   |  1 -
>  2 files changed, 37 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
> b/drivers/gpu/drm/radeon/radeon_cursor.c
> index 45e5406..fa66174 100644
> --- a/drivers/gpu/drm/radeon/radeon_cursor.c
> +++ b/drivers/gpu/drm/radeon/radeon_cursor.c
> @@ -205,8 +205,9 @@ static int radeon_cursor_move_locked(struct
> drm_crtc *crtc, int x, int y)
>   | (x << 16)
>   | y));
>   /* offset is from DISP(2)_BASE_ADDRESS */
> - WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
> (radeon_crtc->legacy_cursor_offset +
> -   (yorigin 
> * 256)));
> + WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
> +radeon_crtc->cursor_addr - 
> radeon_crtc->legacy_display_base_addr +
> +yorigin * 256);
>   }
> 
>   radeon_crtc->cursor_x = x;
> @@ -227,51 +228,32 @@ int radeon_crtc_cursor_move(struct drm_crtc 
> *crtc,
>   return ret;
>  }
> 
> -static int radeon_set_cursor(struct drm_crtc *crtc, struct 
> drm_gem_object *obj)
> +static void radeon_set_cursor(struct drm_crtc *crtc)
>  {
>   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
>   struct radeon_device *rdev = crtc->dev->dev_private;
> - struct radeon_bo *robj = gem_to_radeon_bo(obj);
> - uint64_t gpu_addr;
> - int ret;
> -
> - ret = radeon_bo_reserve(robj, false);
> - if (unlikely(ret != 0))
> - goto fail;
> - /* Only 27 bit offset for legacy cursor */
> - ret = radeon_bo_pin_restricted(robj, RADEON_GEM_DOMAIN_VRAM,
> -ASIC_IS_AVIVO(rdev) ? 0 : 1 << 27,
> -_addr);
> - radeon_bo_unreserve(robj);
> - if (ret)
> - goto fail;
> 
>   if (ASIC_IS_DCE4(rdev)) {
>   WREG32(EVERGREEN_CUR_SURFACE_ADDRESS_HIGH + 
> radeon_crtc->crtc_offset,
> -upper_32_bits(gpu_addr));
> +upper_32_bits(radeon_crtc->cursor_addr));
>   WREG32(EVERGREEN_CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
> -gpu_addr & 0x);
> +lower_32_bits(radeon_crtc->cursor_addr));
>   } else if (ASIC_IS_AVIVO(rdev)) {
>   if (rdev->family >= CHIP_RV770) {
>   if (radeon_crtc->crtc_id)
> - WREG32(R700_D2CUR_SURFACE_ADDRESS_HIGH, 
> upper_32_bits(gpu_addr));
> + WREG32(R700_D2CUR_SURFACE_ADDRESS_HIGH,
> +upper_32_bits(radeon_crtc->cursor_addr));
>   else
> - WREG32(R700_D1CUR_SURFACE_ADDRESS_HIGH, 
> upper_32_bits(gpu_addr));
> + WREG32(R700_D1CUR_SURFACE_ADDRESS_HIGH,
> +upper_32_bits(radeon_crtc->cursor_addr));
>   }
>   WREG32(AVIVO_D1CUR_SURFACE_ADDRESS + radeon_crtc->crtc_offset,
> -gpu_addr & 0x);
> +lower_32_bits(radeon_crtc->cursor_addr));
>   } else {
> - radeon_crtc->legacy_cursor_offset = gpu_addr -
> radeon_crtc->legacy_display_base_addr;
>   /* offset is from DISP(2)_BASE_ADDRESS */
> - WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
> radeon_crtc->legacy_cursor_offset);
> + WREG32(RADEON_CUR_OFFSET + radeon_crtc->crtc_offset,
> +radeon_crtc->cursor_addr - 
> radeon_crtc->legacy_display_base_addr);
>   }
> -
> - return 0;
> -
> -fail:
> - drm_gem_object_unreference_unlocked(obj);
> -
> - return ret;
>  }
> 
>  int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
> @@ -283,7 +265,9 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
>   int32_t hot_y)
>  {
>   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> + struct radeon_device *rdev = crtc->dev->dev_private;
>   struct drm_gem_object *obj;
> + struct radeon_bo *robj;
>   int ret;
> 
>   if (!handle) {
> @@ -305,6 +289,23 @@ int radeon_crtc_cursor_set2(struct drm_crtc *crtc,
>   return -ENOENT;
>   }
> 
> + robj = gem_to_radeon_bo(obj);
> + 

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Daniel Vetter]

On Wed, Jul 08, 2015 at 08:25:07PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 19:52 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> >> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> >>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
>  Op 07-07-15 om 18:43 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>  Op 07-07-15 om 11:18 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> >> This allows the first atomic call during hw init to be a real 
> >> modeset,
> >> which is useful for forcing a recalculation.
> > fbcon is optional, you can't rely on anything being done in any 
> > specific
> > way. What exactly do you need this for, what's the implications?
>  In the hw readout I noticed some warnings when I wasn't setting any 
>  mode property in the readout.
>  I want the first function to be the modeset, so we have a sane base 
>  to commit changes on.
>  Ideally this whole function would have a atomic counterpart which 
>  does it in one go. :)
> >>> Yeah. Otoh as soon as we have atomic modeset working we can replace 
> >>> all
> >>> the legacy entry points with atomic helpers, and then even 
> >>> plane_disable
> >>> will be a full atomic modeset.
> >>>
> >>> What did fall apart with just touching properties/planes now?
> >> Also when i915 is fully atomic it calculates in 
> >> intel_modeset_compute_config
> >> if a modeset is needed after the first atomic call. Right now because
> >> intel_modeset_compute_config is only called in set_config so this 
> >> works as expected.
> >> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
> >> and if the final mode is different this will introduce a double 
> >> modeset.
> > For expensive properties (i.e. a no-op changes causes something that 
> > takes
> > time like modeset or vblank wait) we need to make sure we filter them 
> > out
> > in atomic_check. Yeah not quite there yet with pure atomic, but 
> > meanwhile
> > the existing legacy set_prop functions should all filter out no-op 
> > changes
> > themselves. If we don't do that for rotation then that's a bug.
> >
> > Same for disabling planes harder, that shouldn't take time. Especially
> > since fbcon only force-disable non-primary plane, and for driver load
> > that's the exact thing we already do in the driver anyway.
>  Something like this?
>  ---
>  diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>  b/drivers/gpu/drm/drm_atomic_helper.c
>  index a1d4e13f3908..2989232f4996 100644
>  --- a/drivers/gpu/drm/drm_atomic_helper.c
>  +++ b/drivers/gpu/drm/drm_atomic_helper.c
>  @@ -30,6 +30,7 @@
>   #include 
>   #include 
>   #include 
>  +#include "drm_crtc_internal.h"
>   #include 
>   
>   /**
>  @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct 
>  drm_crtc *crtc,
>   {
>   struct drm_atomic_state *state;
>   struct drm_crtc_state *crtc_state;
>  -int ret = 0;
>  +uint64_t retval;
>  +int ret;
>  +
>  +ret = drm_atomic_get_property(>base, property, );
>  +if (!ret && val == retval)
>  +return 0;
>   
>   state = drm_atomic_state_alloc(crtc->dev);
>   if (!state)
>  @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct 
>  drm_plane *plane,
>   {
>   struct drm_atomic_state *state;
>   struct drm_plane_state *plane_state;
>  -int ret = 0;
>  +uint64_t retval;
>  +int ret;
>  +
>  +ret = drm_atomic_get_property(>base, property, );
>  +if (!ret && val == retval)
>  +return 0;
>   
>   state = drm_atomic_state_alloc(plane->dev);
>   if (!state)
>  @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct 
>  drm_connector *connector,
>   {
>   struct drm_atomic_state *state;
>   struct drm_connector_state *connector_state;
>  -int ret = 0;
>  +uint64_t retval;
>  +int ret;
>  +
>  +ret = drm_atomic_get_property(>base, property, 
>  );
>  +if (!ret && val == retval)
>  +return 0;
>   
>   state = drm_atomic_state_alloc(connector->dev);
>   if (!state)
> >>> The reason I didn't do this is that a prop change might still result in no
> >>> 

Wayland and GLES1 (Re: R200 DRM/KMS)

[Steven Newbury]

On Wed, 2015-07-08 at 21:56 +0100, Steven Newbury wrote:
> On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> > On Mon, 06 Jul 2015 22:50:30 +0100
> > Steven Newbury  wrote:
> > 
> > > Would gles1 be sufficient to run a Wayland compositor, I'm
> > > guessing probably not..?
> > 
> > If you can find a Wayland compositor that is written to composite 
> > with
> > GLES1, that's all you need from the "Wayland side". (Yeah, this has
> > nothing to do with Wayland per se.) Compositing in itself without 
> > any
> > effects is very simple, as long as you get the textures up.
> > 
> > Or, if you find a Wayland compositor written to use desktop OpenGL 
> > for
> > compositing and does not use features your GL driver does not 
> > expose,
> > that's good too.
> > 
> Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?
> 
To answer my own question, it seems that is possible.  I wonder if it
works with mutter/cogl???

> > Absolutely nothing about Wayland limits your choice of the GL 
> > flavour -
> > even more so as the compositor is not running *on* Wayland.
> > 
> > Also, the question of running GL apps on Wayland is a whole another
> > matter. There used to be a common misconception that Wayland had
> > something to do with only allowing GLES.
> > 
> > Finally, there is the option of software rendering for 
> > composition...
> > 
> Well, considering I was wondering about running Wayland on ancient
> hardware, perhaps software compositing wouldn't be ideal! ;-)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/0cc564ac/attachment.sig>

Wayland and GLES1 (Re: R200 DRM/KMS)

[Steven Newbury]

On Tue, 2015-07-07 at 09:18 +0300, Pekka Paalanen wrote:
> On Mon, 06 Jul 2015 22:50:30 +0100
> Steven Newbury  wrote:
> 
> > Would gles1 be sufficient to run a Wayland compositor, I'm
> > guessing probably not..?
> 
> If you can find a Wayland compositor that is written to composite 
> with
> GLES1, that's all you need from the "Wayland side". (Yeah, this has
> nothing to do with Wayland per se.) Compositing in itself without any
> effects is very simple, as long as you get the textures up.
> 
> Or, if you find a Wayland compositor written to use desktop OpenGL 
> for
> compositing and does not use features your GL driver does not expose,
> that's good too.
> 
Is desktop OpenGL accessible from "EGL_PLATFORM=drm"?

> Absolutely nothing about Wayland limits your choice of the GL 
> flavour -
> even more so as the compositor is not running *on* Wayland.
> 
> Also, the question of running GL apps on Wayland is a whole another
> matter. There used to be a common misconception that Wayland had
> something to do with only allowing GLES.
> 
> Finally, there is the option of software rendering for composition...
> 
Well, considering I was wondering about running Wayland on ancient
hardware, perhaps software compositing wouldn't be ideal! ;-)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/b74c681e/attachment.sig>

[PATCH] drm/radeon: disable vce init on cayman (v2)

[Christian König]

On 08.07.2015 21:28, Alex Deucher wrote:
> Cayman does not have vce.  There were a few places in the
> shared cayman/TV code where we were trying to do vce stuff.
>
> v2: remove -ENOENT check
>
> Signed-off-by: Alex Deucher 

Reviewed-by: Christian König 

> ---
>   drivers/gpu/drm/radeon/ni.c | 25 ++---
>   1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 8e5aeeb..158872e 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -2162,18 +2162,20 @@ static int cayman_startup(struct radeon_device *rdev)
>   DRM_ERROR("radeon: failed initializing UVD (%d).\n", r);
>   }
>   
> - ring = >ring[TN_RING_TYPE_VCE1_INDEX];
> - if (ring->ring_size)
> - r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
> + if (rdev->family == CHIP_ARUBA) {
> + ring = >ring[TN_RING_TYPE_VCE1_INDEX];
> + if (ring->ring_size)
> + r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 
> 0x0);
>   
> - ring = >ring[TN_RING_TYPE_VCE2_INDEX];
> - if (ring->ring_size)
> - r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
> + ring = >ring[TN_RING_TYPE_VCE2_INDEX];
> + if (ring->ring_size)
> + r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 
> 0x0);
>   
> - if (!r)
> - r = vce_v1_0_init(rdev);
> - else if (r != -ENOENT)
> - DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
> + if (!r)
> + r = vce_v1_0_init(rdev);
> + if (r)
> + DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
> + }
>   
>   r = radeon_ib_pool_init(rdev);
>   if (r) {
> @@ -2396,7 +2398,8 @@ void cayman_fini(struct radeon_device *rdev)
>   radeon_irq_kms_fini(rdev);
>   uvd_v1_0_fini(rdev);
>   radeon_uvd_fini(rdev);
> - radeon_vce_fini(rdev);
> + if (rdev->family == CHIP_ARUBA)
> + radeon_vce_fini(rdev);
>   cayman_pcie_gart_fini(rdev);
>   r600_vram_scratch_fini(rdev);
>   radeon_gem_fini(rdev);

[PATCH] drm: sti: add moduleparam to disable fbdev

[John Hunter]

On Wed, Jul 8, 2015 at 8:50 PM, Benjamin Gaignard <
benjamin.gaignard at linaro.org> wrote:

> Useful to avoid recompiling to enable/disable fbdev.
>
> Signed-off-by: Benjamin Gaignard 
>

Reviewed-by: Zhao Junwang 

Bochs has the moduleparam for fbdev, lgtm.


> ---
>  drivers/gpu/drm/sti/Kconfig   |  6 --
>  drivers/gpu/drm/sti/sti_drm_drv.c | 13 -
>  2 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index fbccc10..e3aa5af 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -9,9 +9,3 @@ config DRM_STI
> select FW_LOADER_USER_HELPER_FALLBACK
> help
>   Choose this option to enable DRM on STM stiH41x chipset
> -
> -config DRM_STI_FBDEV
> -   bool "DRM frame buffer device for STMicroelectronics SoC stiH41x
> Serie"
> -   depends on DRM_STI
> -   help
> - Choose this option to enable FBDEV on top of DRM for STM stiH41x
> chipset
> diff --git a/drivers/gpu/drm/sti/sti_drm_drv.c
> b/drivers/gpu/drm/sti/sti_drm_drv.c
> index 59d558b..d0fb54a 100644
> --- a/drivers/gpu/drm/sti/sti_drm_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drm_drv.c
> @@ -30,6 +30,10 @@
>  #define STI_MAX_FB_HEIGHT  4096
>  #define STI_MAX_FB_WIDTH   4096
>
> +static bool fbdev;
> +MODULE_PARM_DESC(fbdev, "Enable fbdev compat layer");
> +module_param(fbdev, bool, S_IRUGO | S_IWUSR);
> +
>  static void sti_drm_atomic_schedule(struct sti_drm_private *private,
>   struct drm_atomic_state *state)
>  {
> @@ -160,11 +164,10 @@ static int sti_drm_load(struct drm_device *dev,
> unsigned long flags)
>
> drm_mode_config_reset(dev);
>
> -#ifdef CONFIG_DRM_STI_FBDEV
> -   drm_fbdev_cma_init(dev, 32,
> -  dev->mode_config.num_crtc,
> -  dev->mode_config.num_connector);
> -#endif
> +   if (fbdev)
> +   drm_fbdev_cma_init(dev, 32, dev->mode_config.num_crtc,
> +  dev->mode_config.num_connector);
> +
> return 0;
>  }
>
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/a17fc8ea/attachment.html>

[PATCH] GPU-DRM-Tegra: Delete an unnecessary check before the function call "vunmap"

[SF Markus Elfring]

> From: Markus Elfring 
> Date: Thu, 5 Feb 2015 10:12:51 +0100
> 
> The vunmap() function performs 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/tegra/fb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
> index e9c715d..803598e 100644
> --- a/drivers/gpu/drm/tegra/fb.c
> +++ b/drivers/gpu/drm/tegra/fb.c
> @@ -66,7 +66,7 @@ static void tegra_fb_destroy(struct drm_framebuffer 
> *framebuffer)
>   struct tegra_bo *bo = fb->planes[i];
>  
>   if (bo) {
> - if (bo->pages && bo->vaddr)
> + if (bo->pages)
>   vunmap(bo->vaddr);
>  
>   drm_gem_object_unreference_unlocked(>gem);
> 

Would you like to integrate this update suggestion
into another source code repository?

Regards,
Markus

[PATCH 1/2] drm/radeon: allways add the VM clear duplicate

[Christian König]

On 08.07.2015 18:33, Alex Deucher wrote:
> On Wed, Jul 8, 2015 at 12:31 PM, Christian König
>  wrote:
>> On 08.07.2015 18:14, Alex Deucher wrote:
>>> On Wed, Jul 8, 2015 at 12:08 PM, Christian König
>>>  wrote:
 On 08.07.2015 17:57, Alex Deucher wrote:
> On Wed, Jul 8, 2015 at 3:56 AM, Christian König
> 
> wrote:
>> From: Christian König 
>>
>> We need to allways add the VM clear duplicate of the BO_VA,
>> no matter what the old status was.
>>
>> Signed-off-by: Christian König 
>> Test-by: hadack at gmx.de
> This patch does not apply cleanly.  It also adds an undefined label
> error_unreserve.  Is there an additional patch required?

 That's possible, but I thought the depending patch would have already
 been
 upstream.

 Can you create a drm-fixes-4.2 branch I can rebase on?
>>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.2-wip
>>
>> Ah, here is the problem. This branch don't yet contains the fixes which went
>> upstream with 4.1.
>>
>> What should we do? I don't want to change those patches and create a merge
>> conflict when you merge in 4.1.
> I'll rebase by tree on Linus' tree.  Dave is on vacation so his tree is 
> lagging.

Sounds good, let me know when you have updated the branch and there are 
still conflicts.

Regards,
Christian.

>
> Alex
>
>> Christian.
>>
>>
>>> Thanks,
>>>
>>> Alex
>>>
 Thanks,
 Christian.


> Alex
>
>> ---
>> drivers/gpu/drm/radeon/radeon_vm.c | 34
>> --
>> 1 file changed, 16 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
>> b/drivers/gpu/drm/radeon/radeon_vm.c
>> index ec10533..0310965 100644
>> --- a/drivers/gpu/drm/radeon/radeon_vm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
>> @@ -493,29 +493,27 @@ int radeon_vm_bo_set_addr(struct radeon_device
>> *rdev,
>>}
>>
>>if (bo_va->it.start || bo_va->it.last) {
>> -   spin_lock(>status_lock);
>> -   if (list_empty(_va->vm_status)) {
>> -   /* add a clone of the bo_va to clear the old
>> address */
>> -   struct radeon_bo_va *tmp;
>> -   spin_unlock(>status_lock);
>> -   tmp = kzalloc(sizeof(struct radeon_bo_va),
>> GFP_KERNEL);
>> -   if (!tmp) {
>> -   mutex_unlock(>mutex);
>> -   r = -ENOMEM;
>> -   goto error_unreserve;
>> -   }
>> -   tmp->it.start = bo_va->it.start;
>> -   tmp->it.last = bo_va->it.last;
>> -   tmp->vm = vm;
>> -   tmp->bo = radeon_bo_ref(bo_va->bo);
>> -   spin_lock(>status_lock);
>> -   list_add(>vm_status, >freed);
>> +   /* add a clone of the bo_va to clear the old address */
>> +   struct radeon_bo_va *tmp;
>> +   tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
>> +   if (!tmp) {
>> +   mutex_unlock(>mutex);
>> +   r = -ENOMEM;
>> +   goto error_unreserve;
>>}
>> -   spin_unlock(>status_lock);
>> +   tmp->it.start = bo_va->it.start;
>> +   tmp->it.last = bo_va->it.last;
>> +   tmp->vm = vm;
>> +   tmp->bo = radeon_bo_ref(bo_va->bo);
>>
>>interval_tree_remove(_va->it, >va);
>>bo_va->it.start = 0;
>>bo_va->it.last = 0;
>> +
>> +   spin_lock(>status_lock);
>> +   list_del_init(_va->vm_status);
>> +   list_add(>vm_status, >freed);
>> +   spin_unlock(>status_lock);
>>}
>>
>>if (soffset || eoffset) {
>> --
>> 1.9.1
>>

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Maarten Lankhorst]

Op 08-07-15 om 19:52 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
>> Op 08-07-15 om 10:55 schreef Daniel Vetter:
>>> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
 Op 07-07-15 om 18:43 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 14:10 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
 Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>> This allows the first atomic call during hw init to be a real 
>> modeset,
>> which is useful for forcing a recalculation.
> fbcon is optional, you can't rely on anything being done in any 
> specific
> way. What exactly do you need this for, what's the implications?
 In the hw readout I noticed some warnings when I wasn't setting any 
 mode property in the readout.
 I want the first function to be the modeset, so we have a sane base to 
 commit changes on.
 Ideally this whole function would have a atomic counterpart which does 
 it in one go. :)
>>> Yeah. Otoh as soon as we have atomic modeset working we can replace all
>>> the legacy entry points with atomic helpers, and then even plane_disable
>>> will be a full atomic modeset.
>>>
>>> What did fall apart with just touching properties/planes now?
>> Also when i915 is fully atomic it calculates in 
>> intel_modeset_compute_config
>> if a modeset is needed after the first atomic call. Right now because
>> intel_modeset_compute_config is only called in set_config so this works 
>> as expected.
>> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
>> and if the final mode is different this will introduce a double modeset.
> For expensive properties (i.e. a no-op changes causes something that takes
> time like modeset or vblank wait) we need to make sure we filter them out
> in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
> the existing legacy set_prop functions should all filter out no-op changes
> themselves. If we don't do that for rotation then that's a bug.
>
> Same for disabling planes harder, that shouldn't take time. Especially
> since fbcon only force-disable non-primary plane, and for driver load
> that's the exact thing we already do in the driver anyway.
 Something like this?
 ---
 diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
 b/drivers/gpu/drm/drm_atomic_helper.c
 index a1d4e13f3908..2989232f4996 100644
 --- a/drivers/gpu/drm/drm_atomic_helper.c
 +++ b/drivers/gpu/drm/drm_atomic_helper.c
 @@ -30,6 +30,7 @@
  #include 
  #include 
  #include 
 +#include "drm_crtc_internal.h"
  #include 
  
  /**
 @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc 
 *crtc,
  {
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
 -  int ret = 0;
 +  uint64_t retval;
 +  int ret;
 +
 +  ret = drm_atomic_get_property(>base, property, );
 +  if (!ret && val == retval)
 +  return 0;
  
state = drm_atomic_state_alloc(crtc->dev);
if (!state)
 @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct 
 drm_plane *plane,
  {
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
 -  int ret = 0;
 +  uint64_t retval;
 +  int ret;
 +
 +  ret = drm_atomic_get_property(>base, property, );
 +  if (!ret && val == retval)
 +  return 0;
  
state = drm_atomic_state_alloc(plane->dev);
if (!state)
 @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct 
 drm_connector *connector,
  {
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
 -  int ret = 0;
 +  uint64_t retval;
 +  int ret;
 +
 +  ret = drm_atomic_get_property(>base, property, );
 +  if (!ret && val == retval)
 +  return 0;
  
state = drm_atomic_state_alloc(connector->dev);
if (!state)
>>> The reason I didn't do this is that a prop change might still result in no
>>> hw state change (e.g. if you go automitic->explicit setting matching
>>> automatic one). Hence I think we need to solve this in lower levels
>>> anyway, i.e. in when computing the config. But it shouldn't cause trouble
>>> yet.
>> Is that a ack or nack?
> I think we shouldn't need this really for i915, and it might cover up
> bugs. I prefer we just do the evade modeset logic you've implemented once
> we switch over to atomic props. Since atm we only have atomic props which
> get updated in pageflips we shouldn't have serious 

[PATCH] drm/radeon: disable vce init on cayman

[Christian König]

On 08.07.2015 19:44, Alex Deucher wrote:
> Cayman does not have vce.  There were a few places in the
> shared cayman/TV code where we were trying to do vce stuff.
>
> Signed-off-by: Alex Deucher 

If I remember correctly that was the reason we have the "if (r != 
-ENOENT)" and "if (ring->ring_size)" checks in the code. E.g. if VCE 
isn't supported ring->ring_size is zero and vce_v1_0_init return -ENOENT.

So when we make the check implicit I think we should at least remove the 
-ENOENT check.

Regards,
Christian.

> ---
>   drivers/gpu/drm/radeon/ni.c | 25 ++---
>   1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 6a8afe2..2b2e177 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -2185,18 +2185,20 @@ static int cayman_startup(struct radeon_device *rdev)
>   DRM_ERROR("radeon: failed initializing UVD (%d).\n", r);
>   }
>   
> - ring = >ring[TN_RING_TYPE_VCE1_INDEX];
> - if (ring->ring_size)
> - r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
> + if (rdev->family == CHIP_ARUBA) {
> + ring = >ring[TN_RING_TYPE_VCE1_INDEX];
> + if (ring->ring_size)
> + r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 
> 0x0);
>   
> - ring = >ring[TN_RING_TYPE_VCE2_INDEX];
> - if (ring->ring_size)
> - r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
> + ring = >ring[TN_RING_TYPE_VCE2_INDEX];
> + if (ring->ring_size)
> + r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 
> 0x0);
>   
> - if (!r)
> - r = vce_v1_0_init(rdev);
> - else if (r != -ENOENT)
> - DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
> + if (!r)
> + r = vce_v1_0_init(rdev);
> + else if (r != -ENOENT)
> + DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
> + }
>   
>   r = radeon_ib_pool_init(rdev);
>   if (r) {
> @@ -2419,7 +2421,8 @@ void cayman_fini(struct radeon_device *rdev)
>   radeon_irq_kms_fini(rdev);
>   uvd_v1_0_fini(rdev);
>   radeon_uvd_fini(rdev);
> - radeon_vce_fini(rdev);
> + if (rdev->family == CHIP_ARUBA)
> + radeon_vce_fini(rdev);
>   cayman_pcie_gart_fini(rdev);
>   r600_vram_scratch_fini(rdev);
>   radeon_gem_fini(rdev);

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Daniel Vetter]

On Wed, Jul 08, 2015 at 06:35:47PM +0200, Maarten Lankhorst wrote:
> Op 08-07-15 om 10:55 schreef Daniel Vetter:
> > On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
>  Op 07-07-15 om 14:10 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 11:18 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>  This allows the first atomic call during hw init to be a real 
>  modeset,
>  which is useful for forcing a recalculation.
> >>> fbcon is optional, you can't rely on anything being done in any 
> >>> specific
> >>> way. What exactly do you need this for, what's the implications?
> >> In the hw readout I noticed some warnings when I wasn't setting any 
> >> mode property in the readout.
> >> I want the first function to be the modeset, so we have a sane base to 
> >> commit changes on.
> >> Ideally this whole function would have a atomic counterpart which does 
> >> it in one go. :)
> > Yeah. Otoh as soon as we have atomic modeset working we can replace all
> > the legacy entry points with atomic helpers, and then even plane_disable
> > will be a full atomic modeset.
> >
> > What did fall apart with just touching properties/planes now?
>  Also when i915 is fully atomic it calculates in 
>  intel_modeset_compute_config
>  if a modeset is needed after the first atomic call. Right now because
>  intel_modeset_compute_config is only called in set_config so this works 
>  as expected.
>  Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
>  and if the final mode is different this will introduce a double modeset.
> >>> For expensive properties (i.e. a no-op changes causes something that takes
> >>> time like modeset or vblank wait) we need to make sure we filter them out
> >>> in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
> >>> the existing legacy set_prop functions should all filter out no-op changes
> >>> themselves. If we don't do that for rotation then that's a bug.
> >>>
> >>> Same for disabling planes harder, that shouldn't take time. Especially
> >>> since fbcon only force-disable non-primary plane, and for driver load
> >>> that's the exact thing we already do in the driver anyway.
> >> Something like this?
> >> ---
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index a1d4e13f3908..2989232f4996 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -30,6 +30,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include "drm_crtc_internal.h"
> >>  #include 
> >>  
> >>  /**
> >> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc 
> >> *crtc,
> >>  {
> >>struct drm_atomic_state *state;
> >>struct drm_crtc_state *crtc_state;
> >> -  int ret = 0;
> >> +  uint64_t retval;
> >> +  int ret;
> >> +
> >> +  ret = drm_atomic_get_property(>base, property, );
> >> +  if (!ret && val == retval)
> >> +  return 0;
> >>  
> >>state = drm_atomic_state_alloc(crtc->dev);
> >>if (!state)
> >> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct 
> >> drm_plane *plane,
> >>  {
> >>struct drm_atomic_state *state;
> >>struct drm_plane_state *plane_state;
> >> -  int ret = 0;
> >> +  uint64_t retval;
> >> +  int ret;
> >> +
> >> +  ret = drm_atomic_get_property(>base, property, );
> >> +  if (!ret && val == retval)
> >> +  return 0;
> >>  
> >>state = drm_atomic_state_alloc(plane->dev);
> >>if (!state)
> >> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct 
> >> drm_connector *connector,
> >>  {
> >>struct drm_atomic_state *state;
> >>struct drm_connector_state *connector_state;
> >> -  int ret = 0;
> >> +  uint64_t retval;
> >> +  int ret;
> >> +
> >> +  ret = drm_atomic_get_property(>base, property, );
> >> +  if (!ret && val == retval)
> >> +  return 0;
> >>  
> >>state = drm_atomic_state_alloc(connector->dev);
> >>if (!state)
> > The reason I didn't do this is that a prop change might still result in no
> > hw state change (e.g. if you go automitic->explicit setting matching
> > automatic one). Hence I think we need to solve this in lower levels
> > anyway, i.e. in when computing the config. But it shouldn't cause trouble
> > yet.
> Is that a ack or nack?

I think we shouldn't need this really for i915, and it might cover up
bugs. I prefer we just do the evade modeset logic you've implemented once
we switch over to atomic props. Since atm we only have atomic props which
get updated in pageflips we shouldn't have serious problems here yet (for
setting the rotation prop to 0° 

[PATCH] drm/msm/mdp5:Add DMA pipe planes for MDP5

[Rob Clark]

On Tue, Jul 7, 2015 at 5:17 PM, Jilai Wang  wrote:
> This change is to add planes which use DMA pipes for MDP5.

are DMA pipes only supporting memory->memory operation, or am I
reading too much into the name "DMA"?  I'm wondering if we need to fix
the possible_crtcs param that mdp5_plane_init passes to
drm_universal_plane_init()?

BR,
-R


> Signed-off-by: Jilai Wang 
> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 23 ---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index cbda41d..f40896d 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -316,9 +316,12 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
> static const enum mdp5_pipe crtcs[] = {
> SSPP_RGB0, SSPP_RGB1, SSPP_RGB2, SSPP_RGB3,
> };
> -   static const enum mdp5_pipe pub_planes[] = {
> +   static const enum mdp5_pipe vig_planes[] = {
> SSPP_VIG0, SSPP_VIG1, SSPP_VIG2, SSPP_VIG3,
> };
> +   static const enum mdp5_pipe dma_planes[] = {
> +   SSPP_DMA0, SSPP_DMA1,
> +   };
> struct drm_device *dev = mdp5_kms->dev;
> struct msm_drm_private *priv = dev->dev_private;
> const struct mdp5_cfg_hw *hw_cfg;
> @@ -361,12 +364,26 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
> for (i = 0; i < hw_cfg->pipe_vig.count; i++) {
> struct drm_plane *plane;
>
> -   plane = mdp5_plane_init(dev, pub_planes[i], false,
> +   plane = mdp5_plane_init(dev, vig_planes[i], false,
> hw_cfg->pipe_vig.base[i], hw_cfg->pipe_vig.caps);
> if (IS_ERR(plane)) {
> ret = PTR_ERR(plane);
> dev_err(dev->dev, "failed to construct %s plane: 
> %d\n",
> -   pipe2name(pub_planes[i]), ret);
> +   pipe2name(vig_planes[i]), ret);
> +   goto fail;
> +   }
> +   }
> +
> +   /* DMA planes */
> +   for (i = 0; i < hw_cfg->pipe_dma.count; i++) {
> +   struct drm_plane *plane;
> +
> +   plane = mdp5_plane_init(dev, dma_planes[i], false,
> +   hw_cfg->pipe_dma.base[i], hw_cfg->pipe_dma.caps);
> +   if (IS_ERR(plane)) {
> +   ret = PTR_ERR(plane);
> +   dev_err(dev->dev, "failed to construct %s plane: 
> %d\n",
> +   pipe2name(dma_planes[i]), ret);
> goto fail;
> }
> }
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>

[PATCH] drm/radeon: disable vce init on cayman

[Deucher, Alexander]

> -Original Message-
> From: Christian König [mailto:deathsimple at vodafone.de]
> Sent: Wednesday, July 08, 2015 2:17 PM
> To: Alex Deucher; dri-devel at lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH] drm/radeon: disable vce init on cayman
> 
> On 08.07.2015 19:44, Alex Deucher wrote:
> > Cayman does not have vce.  There were a few places in the
> > shared cayman/TV code where we were trying to do vce stuff.
> >
> > Signed-off-by: Alex Deucher 
> 
> If I remember correctly that was the reason we have the "if (r !=
> -ENOENT)" and "if (ring->ring_size)" checks in the code. E.g. if VCE
> isn't supported ring->ring_size is zero and vce_v1_0_init return -ENOENT.

The problem is vce_v1_0_init() doesn't return -ENOENT.  So vce_v1_0_start() 
tries to run on cayman and fails leading to problems.

> 
> So when we make the check implicit I think we should at least remove the
> -ENOENT check.

I'll do that.

Alex

> 
> Regards,
> Christian.
> 
> > ---
> >   drivers/gpu/drm/radeon/ni.c | 25 ++---
> >   1 file changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> > index 6a8afe2..2b2e177 100644
> > --- a/drivers/gpu/drm/radeon/ni.c
> > +++ b/drivers/gpu/drm/radeon/ni.c
> > @@ -2185,18 +2185,20 @@ static int cayman_startup(struct radeon_device
> *rdev)
> > DRM_ERROR("radeon: failed initializing UVD
> (%d).\n", r);
> > }
> >
> > -   ring = >ring[TN_RING_TYPE_VCE1_INDEX];
> > -   if (ring->ring_size)
> > -   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
> > +   if (rdev->family == CHIP_ARUBA) {
> > +   ring = >ring[TN_RING_TYPE_VCE1_INDEX];
> > +   if (ring->ring_size)
> > +   r = radeon_ring_init(rdev, ring, ring->ring_size, 0,
> 0x0);
> >
> > -   ring = >ring[TN_RING_TYPE_VCE2_INDEX];
> > -   if (ring->ring_size)
> > -   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
> > +   ring = >ring[TN_RING_TYPE_VCE2_INDEX];
> > +   if (ring->ring_size)
> > +   r = radeon_ring_init(rdev, ring, ring->ring_size, 0,
> 0x0);
> >
> > -   if (!r)
> > -   r = vce_v1_0_init(rdev);
> > -   else if (r != -ENOENT)
> > -   DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
> > +   if (!r)
> > +   r = vce_v1_0_init(rdev);
> > +   else if (r != -ENOENT)
> > +   DRM_ERROR("radeon: failed initializing VCE (%d).\n",
> r);
> > +   }
> >
> > r = radeon_ib_pool_init(rdev);
> > if (r) {
> > @@ -2419,7 +2421,8 @@ void cayman_fini(struct radeon_device *rdev)
> > radeon_irq_kms_fini(rdev);
> > uvd_v1_0_fini(rdev);
> > radeon_uvd_fini(rdev);
> > -   radeon_vce_fini(rdev);
> > +   if (rdev->family == CHIP_ARUBA)
> > +   radeon_vce_fini(rdev);
> > cayman_pcie_gart_fini(rdev);
> > r600_vram_scratch_fini(rdev);
> > radeon_gem_fini(rdev);

[PATCH:libdrm] include & directly for major() and minor()

[Emil Velikov]

On 8 July 2015 at 18:41, Alan Coopersmith  
wrote:
> Linux seems to pick these up via another header, but Solaris needs them
> explictly included, or we get undefined symbol errors for major & minor.
>
> v2: use headers documented in makedev(3C) man page instead of sysmacros.h
>
> Signed-off-by: Alan Coopersmith 
> ---
>  libkms/linux.c |2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libkms/linux.c b/libkms/linux.c
> index 4d47148..53e03c3 100644
> --- a/libkms/linux.c
> +++ b/libkms/linux.c
> @@ -40,6 +40,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
I'll add the HAVE_SYS_MKDEV_H guard around the latter, and push this
in the next few days. Unless someone objects that is ;-)

Thank you Alan,
Emil

DRM-vmwgfx: Deletion of an unnecessary check before the function call "vfree"

[SF Markus Elfring]

> Reviewed-by: Zhao Junwang  
> 
> kfree will check that.

How does this feedback fit to a check before a call
of the vfree() function?

Regards,
Markus

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Maarten Lankhorst]

Op 08-07-15 om 10:55 schreef Daniel Vetter:
> On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 18:43 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
 Op 07-07-15 om 14:10 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 11:18 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
 This allows the first atomic call during hw init to be a real modeset,
 which is useful for forcing a recalculation.
>>> fbcon is optional, you can't rely on anything being done in any specific
>>> way. What exactly do you need this for, what's the implications?
>> In the hw readout I noticed some warnings when I wasn't setting any mode 
>> property in the readout.
>> I want the first function to be the modeset, so we have a sane base to 
>> commit changes on.
>> Ideally this whole function would have a atomic counterpart which does 
>> it in one go. :)
> Yeah. Otoh as soon as we have atomic modeset working we can replace all
> the legacy entry points with atomic helpers, and then even plane_disable
> will be a full atomic modeset.
>
> What did fall apart with just touching properties/planes now?
 Also when i915 is fully atomic it calculates in 
 intel_modeset_compute_config
 if a modeset is needed after the first atomic call. Right now because
 intel_modeset_compute_config is only called in set_config so this works as 
 expected.
 Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
 and if the final mode is different this will introduce a double modeset.
>>> For expensive properties (i.e. a no-op changes causes something that takes
>>> time like modeset or vblank wait) we need to make sure we filter them out
>>> in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
>>> the existing legacy set_prop functions should all filter out no-op changes
>>> themselves. If we don't do that for rotation then that's a bug.
>>>
>>> Same for disabling planes harder, that shouldn't take time. Especially
>>> since fbcon only force-disable non-primary plane, and for driver load
>>> that's the exact thing we already do in the driver anyway.
>> Something like this?
>> ---
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index a1d4e13f3908..2989232f4996 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -30,6 +30,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include "drm_crtc_internal.h"
>>  #include 
>>  
>>  /**
>> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc 
>> *crtc,
>>  {
>>  struct drm_atomic_state *state;
>>  struct drm_crtc_state *crtc_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(>base, property, );
>> +if (!ret && val == retval)
>> +return 0;
>>  
>>  state = drm_atomic_state_alloc(crtc->dev);
>>  if (!state)
>> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct drm_plane 
>> *plane,
>>  {
>>  struct drm_atomic_state *state;
>>  struct drm_plane_state *plane_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(>base, property, );
>> +if (!ret && val == retval)
>> +return 0;
>>  
>>  state = drm_atomic_state_alloc(plane->dev);
>>  if (!state)
>> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct 
>> drm_connector *connector,
>>  {
>>  struct drm_atomic_state *state;
>>  struct drm_connector_state *connector_state;
>> -int ret = 0;
>> +uint64_t retval;
>> +int ret;
>> +
>> +ret = drm_atomic_get_property(>base, property, );
>> +if (!ret && val == retval)
>> +return 0;
>>  
>>  state = drm_atomic_state_alloc(connector->dev);
>>  if (!state)
> The reason I didn't do this is that a prop change might still result in no
> hw state change (e.g. if you go automitic->explicit setting matching
> automatic one). Hence I think we need to solve this in lower levels
> anyway, i.e. in when computing the config. But it shouldn't cause trouble
> yet.
Is that a ack or nack?
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 424c83323aaa..5bab7bff8a15 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -1327,7 +1327,8 @@ void drm_plane_force_disable(struct drm_plane *plane)
>>  {
>>  int ret;
>>  
>> -if (!plane->fb)
>> +if ((plane->state && !plane->state->fb) ||
>> +(!plane->state && !plane->fb))
>>  return;
> Nah, atomic helpers should figure this out imo. Since if userspace does
> the same (loop over all planes) then it won't go through 

[PATCH 1/2] drm/radeon: allways add the VM clear duplicate

[Christian König]

On 08.07.2015 18:14, Alex Deucher wrote:
> On Wed, Jul 8, 2015 at 12:08 PM, Christian König
>  wrote:
>> On 08.07.2015 17:57, Alex Deucher wrote:
>>> On Wed, Jul 8, 2015 at 3:56 AM, Christian König >> vodafone.de>
>>> wrote:
 From: Christian König 

 We need to allways add the VM clear duplicate of the BO_VA,
 no matter what the old status was.

 Signed-off-by: Christian König 
 Test-by: hadack at gmx.de
>>> This patch does not apply cleanly.  It also adds an undefined label
>>> error_unreserve.  Is there an additional patch required?
>>
>> That's possible, but I thought the depending patch would have already been
>> upstream.
>>
>> Can you create a drm-fixes-4.2 branch I can rebase on?
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.2-wip

Ah, here is the problem. This branch don't yet contains the fixes which 
went upstream with 4.1.

What should we do? I don't want to change those patches and create a 
merge conflict when you merge in 4.1.

Christian.

>
> Thanks,
>
> Alex
>
>> Thanks,
>> Christian.
>>
>>
>>> Alex
>>>
 ---
drivers/gpu/drm/radeon/radeon_vm.c | 34
 --
1 file changed, 16 insertions(+), 18 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
 b/drivers/gpu/drm/radeon/radeon_vm.c
 index ec10533..0310965 100644
 --- a/drivers/gpu/drm/radeon/radeon_vm.c
 +++ b/drivers/gpu/drm/radeon/radeon_vm.c
 @@ -493,29 +493,27 @@ int radeon_vm_bo_set_addr(struct radeon_device
 *rdev,
   }

   if (bo_va->it.start || bo_va->it.last) {
 -   spin_lock(>status_lock);
 -   if (list_empty(_va->vm_status)) {
 -   /* add a clone of the bo_va to clear the old
 address */
 -   struct radeon_bo_va *tmp;
 -   spin_unlock(>status_lock);
 -   tmp = kzalloc(sizeof(struct radeon_bo_va),
 GFP_KERNEL);
 -   if (!tmp) {
 -   mutex_unlock(>mutex);
 -   r = -ENOMEM;
 -   goto error_unreserve;
 -   }
 -   tmp->it.start = bo_va->it.start;
 -   tmp->it.last = bo_va->it.last;
 -   tmp->vm = vm;
 -   tmp->bo = radeon_bo_ref(bo_va->bo);
 -   spin_lock(>status_lock);
 -   list_add(>vm_status, >freed);
 +   /* add a clone of the bo_va to clear the old address */
 +   struct radeon_bo_va *tmp;
 +   tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
 +   if (!tmp) {
 +   mutex_unlock(>mutex);
 +   r = -ENOMEM;
 +   goto error_unreserve;
   }
 -   spin_unlock(>status_lock);
 +   tmp->it.start = bo_va->it.start;
 +   tmp->it.last = bo_va->it.last;
 +   tmp->vm = vm;
 +   tmp->bo = radeon_bo_ref(bo_va->bo);

   interval_tree_remove(_va->it, >va);
   bo_va->it.start = 0;
   bo_va->it.last = 0;
 +
 +   spin_lock(>status_lock);
 +   list_del_init(_va->vm_status);
 +   list_add(>vm_status, >freed);
 +   spin_unlock(>status_lock);
   }

   if (soffset || eoffset) {
 --
 1.9.1

[PATCH] drm/msm/mdp5: Add support for msm8x74v1

[Jilai Wang]

msm8x74v1 has different MDP5 version (v1.0) from msm8x74v2 (v1.2).
Add a separate config data to support msm8x74v1.

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 77 +++--
 1 file changed, 73 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index ac1d58f..835a276 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -22,7 +22,76 @@ struct mdp5_cfg_handler {
 /* mdp5_cfg must be exposed (used in mdp5.xml.h) */
 const struct mdp5_cfg_hw *mdp5_cfg = NULL;

-const struct mdp5_cfg_hw msm8x74_config = {
+const struct mdp5_cfg_hw msm8x74v1_config = {
+   .name = "msm8x74v1",
+   .mdp = {
+   .count = 1,
+   .base = { 0x00100 },
+   },
+   .smp = {
+   .mmb_count = 22,
+   .mmb_size = 4096,
+   .clients = {
+   [SSPP_VIG0] =  1, [SSPP_VIG1] =  4, [SSPP_VIG2] =  7,
+   [SSPP_DMA0] = 10, [SSPP_DMA1] = 13,
+   [SSPP_RGB0] = 16, [SSPP_RGB1] = 17, [SSPP_RGB2] = 18,
+   },
+   },
+   .ctl = {
+   .count = 5,
+   .base = { 0x00600, 0x00700, 0x00800, 0x00900, 0x00a00 },
+   .flush_hw_mask = 0x0003,
+   },
+   .pipe_vig = {
+   .count = 3,
+   .base = { 0x01200, 0x01600, 0x01a00 },
+   .caps = MDP_PIPE_CAP_HFLIP |
+   MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE |
+   MDP_PIPE_CAP_CSC   |
+   0,
+   },
+   .pipe_rgb = {
+   .count = 3,
+   .base = { 0x01e00, 0x02200, 0x02600 },
+   .caps = MDP_PIPE_CAP_HFLIP |
+   MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE |
+   0,
+   },
+   .pipe_dma = {
+   .count = 2,
+   .base = { 0x02a00, 0x02e00 },
+   .caps = MDP_PIPE_CAP_HFLIP |
+   MDP_PIPE_CAP_VFLIP |
+   0,
+   },
+   .lm = {
+   .count = 5,
+   .base = { 0x03200, 0x03600, 0x03a00, 0x03e00, 0x04200 },
+   .nb_stages = 5,
+   },
+   .dspp = {
+   .count = 3,
+   .base = { 0x04600, 0x04a00, 0x04e00 },
+   },
+   .pp = {
+   .count = 3,
+   .base = { 0x21b00, 0x21c00, 0x21d00 },
+   },
+   .intf = {
+   .base = { 0x21100, 0x21300, 0x21500, 0x21700 },
+   .connect = {
+   [0] = INTF_eDP,
+   [1] = INTF_DSI,
+   [2] = INTF_DSI,
+   [3] = INTF_HDMI,
+   },
+   },
+   .max_clk = 2,
+};
+
+const struct mdp5_cfg_hw msm8x74v2_config = {
.name = "msm8x74",
.mdp = {
.count = 1,
@@ -71,7 +140,7 @@ const struct mdp5_cfg_hw msm8x74_config = {
},
.ad = {
.count = 2,
-   .base = { 0x13100, 0x13300 }, /* NOTE: no ad in v1.0 */
+   .base = { 0x13100, 0x13300 },
},
.pp = {
.count = 3,
@@ -297,8 +366,8 @@ const struct mdp5_cfg_hw msm8x94_config = {
 };

 static const struct mdp5_cfg_handler cfg_handlers[] = {
-   { .revision = 0, .config = { .hw = _config } },
-   { .revision = 2, .config = { .hw = _config } },
+   { .revision = 0, .config = { .hw = _config } },
+   { .revision = 2, .config = { .hw = _config } },
{ .revision = 3, .config = { .hw = _config } },
{ .revision = 6, .config = { .hw = _config } },
{ .revision = 9, .config = { .hw = _config } },
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] drm/msm/mdp: Add capabilities to MDP planes(V2)

[Jilai Wang]

MDP planes can be implemented using different type of HW pipes,
RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
of pipe has different HW capabilities such as scaling, color space
conversion, decimation... Add a variable in plane data structure
to specify the difference of each plane which comes from mdp5_cfg data
and use it to differenciate the plane operation.
V1: Initial change
V2: Fix a typo in mdp4_kms.h

Signed-off-by: Jilai Wang 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h   | 19 
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c |  7 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c   | 26 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h   | 11 +++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  4 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   | 24 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 73 ++-
 drivers/gpu/drm/msm/mdp/mdp_kms.h | 13 ++
 8 files changed, 114 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
index c1ecb9d..1aaedad 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
@@ -175,27 +175,24 @@ irqreturn_t mdp4_irq(struct msm_kms *kms);
 int mdp4_enable_vblank(struct msm_kms *kms, struct drm_crtc *crtc);
 void mdp4_disable_vblank(struct msm_kms *kms, struct drm_crtc *crtc);

-static inline bool pipe_supports_yuv(enum mdp4_pipe pipe)
+static inline uint32_t mdp4_pipe_caps(enum mdp4_pipe pipe)
 {
switch (pipe) {
case VG1:
case VG2:
case VG3:
case VG4:
-   return true;
+   return MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_CSC;
+   case RGB1:
+   case RGB2:
+   case RGB3:
+   return MDP_PIPE_CAP_SCALE;
default:
-   return false;
+   return 0;
}
 }

-static inline
-uint32_t mdp4_get_formats(enum mdp4_pipe pipe_id, uint32_t *pixel_formats,
-   uint32_t max_formats)
-{
-   return mdp_get_formats(pixel_formats, max_formats,
-   !pipe_supports_yuv(pipe_id));
-}
-
 void mdp4_plane_install_properties(struct drm_plane *plane,
struct drm_mode_object *obj);
 enum mdp4_pipe mdp4_plane_pipe(struct drm_plane *plane);
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index 0d1dbb7..c749489 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -26,6 +26,7 @@ struct mdp4_plane {

enum mdp4_pipe pipe;

+   uint32_t caps;
uint32_t nformats;
uint32_t formats[32];

@@ -380,9 +381,11 @@ struct drm_plane *mdp4_plane_init(struct drm_device *dev,

mdp4_plane->pipe = pipe_id;
mdp4_plane->name = pipe_names[pipe_id];
+   mdp4_plane->caps = mdp4_pipe_caps(pipe_id);

-   mdp4_plane->nformats = mdp4_get_formats(pipe_id, mdp4_plane->formats,
-   ARRAY_SIZE(mdp4_plane->formats));
+   mdp4_plane->nformats = mdp_get_formats(mdp4_plane->formats,
+   ARRAY_SIZE(mdp4_plane->formats),
+   !pipe_supports_yuv(mdp4_plane->caps));

type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(dev, plane, 0xff, _plane_funcs,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 789b02f..ac1d58f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -45,14 +45,20 @@ const struct mdp5_cfg_hw msm8x74_config = {
.pipe_vig = {
.count = 3,
.base = { 0x01200, 0x01600, 0x01a00 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_CSC |
+   MDP_PIPE_CAP_DECIMATION,
},
.pipe_rgb = {
.count = 3,
.base = { 0x01e00, 0x02200, 0x02600 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_DECIMATION,
},
.pipe_dma = {
.count = 2,
.base = { 0x02a00, 0x02e00 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP,
},
.lm = {
.count = 5,
@@ -113,14 +119,20 @@ const struct mdp5_cfg_hw apq8084_config = {
.pipe_vig = {
.count = 4,
.base = { 0x01200, 0x01600, 0x01a00, 0x01e00 },
+   .caps = MDP_PIPE_CAP_HFLIP | MDP_PIPE_CAP_VFLIP |
+   MDP_PIPE_CAP_SCALE | MDP_PIPE_CAP_CSC |
+   MDP_PIPE_CAP_DECIMATION,
},
.pipe_rgb = {
.count = 4,
.base = { 

[PATCH 1/2] drm/radeon: allways add the VM clear duplicate

[Christian König]

On 08.07.2015 17:57, Alex Deucher wrote:
> On Wed, Jul 8, 2015 at 3:56 AM, Christian König  
> wrote:
>> From: Christian König 
>>
>> We need to allways add the VM clear duplicate of the BO_VA,
>> no matter what the old status was.
>>
>> Signed-off-by: Christian König 
>> Test-by: hadack at gmx.de
> This patch does not apply cleanly.  It also adds an undefined label
> error_unreserve.  Is there an additional patch required?

That's possible, but I thought the depending patch would have already 
been upstream.

Can you create a drm-fixes-4.2 branch I can rebase on?

Thanks,
Christian.

> Alex
>
>> ---
>>   drivers/gpu/drm/radeon/radeon_vm.c | 34 --
>>   1 file changed, 16 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
>> b/drivers/gpu/drm/radeon/radeon_vm.c
>> index ec10533..0310965 100644
>> --- a/drivers/gpu/drm/radeon/radeon_vm.c
>> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
>> @@ -493,29 +493,27 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
>>  }
>>
>>  if (bo_va->it.start || bo_va->it.last) {
>> -   spin_lock(>status_lock);
>> -   if (list_empty(_va->vm_status)) {
>> -   /* add a clone of the bo_va to clear the old address 
>> */
>> -   struct radeon_bo_va *tmp;
>> -   spin_unlock(>status_lock);
>> -   tmp = kzalloc(sizeof(struct radeon_bo_va), 
>> GFP_KERNEL);
>> -   if (!tmp) {
>> -   mutex_unlock(>mutex);
>> -   r = -ENOMEM;
>> -   goto error_unreserve;
>> -   }
>> -   tmp->it.start = bo_va->it.start;
>> -   tmp->it.last = bo_va->it.last;
>> -   tmp->vm = vm;
>> -   tmp->bo = radeon_bo_ref(bo_va->bo);
>> -   spin_lock(>status_lock);
>> -   list_add(>vm_status, >freed);
>> +   /* add a clone of the bo_va to clear the old address */
>> +   struct radeon_bo_va *tmp;
>> +   tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
>> +   if (!tmp) {
>> +   mutex_unlock(>mutex);
>> +   r = -ENOMEM;
>> +   goto error_unreserve;
>>  }
>> -   spin_unlock(>status_lock);
>> +   tmp->it.start = bo_va->it.start;
>> +   tmp->it.last = bo_va->it.last;
>> +   tmp->vm = vm;
>> +   tmp->bo = radeon_bo_ref(bo_va->bo);
>>
>>  interval_tree_remove(_va->it, >va);
>>  bo_va->it.start = 0;
>>  bo_va->it.last = 0;
>> +
>> +   spin_lock(>status_lock);
>> +   list_del_init(_va->vm_status);
>> +   list_add(>vm_status, >freed);
>> +   spin_unlock(>status_lock);
>>  }
>>
>>  if (soffset || eoffset) {
>> --
>> 1.9.1
>>

R200 DRM/KMS

[Steven Newbury]

On Wed, 2015-07-08 at 17:10 +0100, Emil Velikov wrote:
> On 8 July 2015 at 14:55, Alex Deucher  wrote:
> > On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury <
> > steve at snewbury.org.uk> wrote:
> > > 
> > > 
> > > On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
> > > > On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury <
> > > > steve at snewbury.org.uk> wrote:
> > > > > 
> > > > > 
> > > > > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> > > > > > On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury <
> > > > > > steve at snewbury.org.uk> wrote:
> > > > > > > 
> > > > > > > I've tried an xserver-1.16, and ddx, libdrm without LTO 
> > > > > > > and with
> > > > > > > gcc4.9.  Exactly the same thing.  I wondered whether the 
> > > > > > > unused i810
> > > > > > > could be interfering but triggering a device "remove" 
> > > > > > > before starting
> > > > > > > X made no difference.
> > > > > > > 
> > > > > > > I'm a bit of a loss.  I suppose I could try writing a 
> > > > > > > simple test for
> > > > > > > drmSetInterfaceVersion().  At least that should 
> > > > > > > determine whether the
> > > > > > > xserver/ddx is in the clear.
> > > > > > > 
> > > > > > > Any other ideas?
> > > > > > > 
> > > > > > 
> > > > > > Can you start a non-X runlevel and start X manually as 
> > > > > > root (assuming
> > > > > > you are using a login manager now)?
> > > > > > 
> > > > > My test program worked fine. I considerably improved it over 
> > > > > the version I posted. I'll send it to the list when I get 
> > > > > back.
> > > > > 
> > > > > I removed the drmSetInterfaceVersion() from radeon_kms.c and 
> > > > > it got much further.  Starting Xserver as root  apparently 
> > > > > started normally, according to the log, although  there was 
> > > > > a permission denied error on mode set during init. I don't 
> > > > > know whether it was related or not, but the display then 
> > > > > hung with a non-blinking cursor. Strange to get a permission 
> > > > > denied as root!
> > > > > 
> > > > > Starting GNOME via gdm gives a working slow X session but 
> > > > > for some reason only uses sw dri even though the Xorg log 
> > > > > shows r200 DRI2 as initialized. Perhaps it's a config error 
> > > > > somewhere.. ?
> > > > > 
> > > > > startx as a regular user just works!
> > > > > 
> > > > > But mutter doesn't, perhaps that's
> > > > > why a gnome session isn't working. It just gives the 
> > > > > following error:
> > > > > Cogl-ERROR **: Failed to create texture 2d due to 
> > > > > size/format constraints
> > > > > 
> > > > > Mutter is supposed to work on r200, right?
> > > > 
> > > > IIRC it tries to use a render buffer format that's not 
> > > > supported by the hw.
> > > Is there anything to be done about it? Have to use a different 
> > > wm/compositor?
> > > 
> > 
> > Another wm or compositor may help.
> > 
> > > Any idea why removing the call from radeon_kms.c worked?
> > 
> > No idea.
> > 
> From a quick look at the actual implementation drmSetInterfaceVersion
> is not something that we want/need to use with KMS drivers.
> 
> In general the original issue sound like the drm driver is not 
> (fully)
> loaded before the xserver/ddx kicks in. Additionally it may be a race
> condition if something else (plymouth) is using the device. In the
> latter case DRM_MASTER might still be held by $(other_app), thus
> attempting to either SetInterfaceVersion or do any modeset operation
> will fail.
> 
> 
Sitting on a KMS console, "systemctl start gdm", no plymouth
installed.  It's just during Xserver initialisation that
drmSetInterfaceVersion() fails.  AFAIK Xserver startup is entirely
single process, single thread.  I've written a little test utility
which works fine on the system in question.

Compile attached file with:
gcc -O2 -o test-drm test-drm.c $(pkg-config --cflags libdrm) $(pkg
-config --libs libdrm)


> Personally I would add a healthy amount of printk/printf though the
> kernel drm + radeon and the ddx.

I guess it doesn't really matter since patching out the code "fixes"
it...
-- next part --
A non-text attachment was scrubbed...
Name: test-drm.c
Type: text/x-csrc
Size: 1783 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/f4f234fa/attachment-0001.c>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/f4f234fa/attachment-0001.sig>

[PATCH] drm/radeon: Report panel connector status as unknown when lid is closed

[Michel Dänzer]

From: Michel Dänzer 

This makes fbcon and desktop environments such as GNOME automatically
not use the panel when the lid is closed.

Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 82 --
 1 file changed, 44 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index cebb65e..2484438 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -23,6 +23,7 @@
  * Authors: Dave Airlie
  *  Alex Deucher
  */
+#include 
 #include 
 #include 
 #include 
@@ -890,25 +891,27 @@ radeon_lvds_detect(struct drm_connector *connector, bool 
force)
if (r < 0)
return connector_status_disconnected;

-   if (encoder) {
-   struct radeon_encoder *radeon_encoder = 
to_radeon_encoder(encoder);
-   struct drm_display_mode *native_mode = 
_encoder->native_mode;
+   if (acpi_lid_open()) {
+   if (encoder) {
+   struct radeon_encoder *radeon_encoder = 
to_radeon_encoder(encoder);
+   struct drm_display_mode *native_mode = 
_encoder->native_mode;

-   /* check if panel is valid */
-   if (native_mode->hdisplay >= 320 && native_mode->vdisplay >= 
240)
-   ret = connector_status_connected;
-   /* don't fetch the edid from the vbios if ddc fails and runpm is
-* enabled so we report disconnected.
-*/
-   if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm != 0))
-   ret = connector_status_disconnected;
-   }
+   /* check if panel is valid */
+   if (native_mode->hdisplay >= 320 && 
native_mode->vdisplay >= 240)
+   ret = connector_status_connected;
+   /* don't fetch the edid from the vbios if ddc fails and 
runpm is
+* enabled so we report disconnected.
+*/
+   if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm 
!= 0))
+   ret = connector_status_disconnected;
+   }

-   /* check for edid as well */
-   radeon_connector_get_edid(connector);
-   if (radeon_connector->edid)
-   ret = connector_status_connected;
-   /* check acpi lid status ??? */
+   /* check for edid as well */
+   radeon_connector_get_edid(connector);
+   if (radeon_connector->edid)
+   ret = connector_status_connected;
+   } else
+   ret = connector_status_unknown;

radeon_connector_update_scratch_regs(connector, ret);
pm_runtime_mark_last_busy(connector->dev->dev);
@@ -1647,29 +1650,32 @@ radeon_dp_detect(struct drm_connector *connector, bool 
force)

if ((connector->connector_type == DRM_MODE_CONNECTOR_eDP) ||
(connector->connector_type == DRM_MODE_CONNECTOR_LVDS)) {
-   if (encoder) {
-   struct radeon_encoder *radeon_encoder = 
to_radeon_encoder(encoder);
-   struct drm_display_mode *native_mode = 
_encoder->native_mode;
+   if (acpi_lid_open()) {
+   if (encoder) {
+   struct radeon_encoder *radeon_encoder = 
to_radeon_encoder(encoder);
+   struct drm_display_mode *native_mode = 
_encoder->native_mode;

-   /* check if panel is valid */
-   if (native_mode->hdisplay >= 320 && 
native_mode->vdisplay >= 240)
+   /* check if panel is valid */
+   if (native_mode->hdisplay >= 320 && 
native_mode->vdisplay >= 240)
+   ret = connector_status_connected;
+   /* don't fetch the edid from the vbios if ddc 
fails and runpm is
+* enabled so we report disconnected.
+*/
+   if ((rdev->flags & RADEON_IS_PX) && 
(radeon_runtime_pm != 0))
+   ret = connector_status_disconnected;
+   }
+   /* eDP is always DP */
+   radeon_dig_connector->dp_sink_type = 
CONNECTOR_OBJECT_ID_DISPLAYPORT;
+   if (!radeon_dig_connector->edp_on)
+   atombios_set_edp_panel_power(connector,
+
ATOM_TRANSMITTER_ACTION_POWER_ON);
+   if (radeon_dp_getdpcd(radeon_connector))
ret = connector_status_connected;
-   /* don't fetch the edid from the vbios if ddc fails and 
runpm 

Device enumeration support in libdrm

[Emil Velikov]

Hello Jammy,

On 8 July 2015 at 06:53, Zhou, Jammy  wrote:
> Hi Emil,
>
>
>
> With our previous RFC patches to add interfaces to support GPU device
> enumeration support in libdrm, the udev mechanism was used. But we found
> that if we introduce the libudev dependency for libdrm, there will be some
> problem to run steam application on recent distributions (for example,
> Ubuntu 14.04 LTS) because of the conflict between the system libudev.so.1
> (loaded by libdrm) and the libudev.so.0 (bundled in steam-runtime and loaded
> by steam application). There are some similar issues as mentioned in the
> links below. Although we can argue that it is application’s problem, can we
> get rid of libudev for the device enumeration before Valve can make
> steam-runtime use system libraries by default? It is much appreciated if you
> can give some suggestions about how we can support device enumeration with
> libdrm.
>
I believe I mentioned it before, perhaps I wasn't clear enough. Rather
than using libudev, manually iterate through sysfs. I agree it's not a
not pretty solution yet the libdrm code already has much weirder
stuff.

Cheers
Emil

[PATCH:libdrm] include directly for major() and minor()

[Emil Velikov]

Hi Alan

On 7 July 2015 at 01:45, Alan Coopersmith  
wrote:
> Linux seems to pick this up via another header, but Solaris needs it
> explictly included, or we get undefined symbol errors for major & minor.
>
A slightly pedandic suggestion:
Can we use sys/types.h + sys/mkdev.h as the manpage suggests. We
already do so in xf86drm.c

Thanks
Emil

R200 DRM/KMS

[Emil Velikov]

On 8 July 2015 at 14:55, Alex Deucher  wrote:
> On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury  
> wrote:
>>
>>
>> On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
>>> On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury  
>>> wrote:
>>> >
>>> >
>>> > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
>>> >> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury >> >> snewbury.org.uk> wrote:
>>> >> >
>>> >> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
>>> >> > gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
>>> >> > could be interfering but triggering a device "remove" before starting
>>> >> > X made no difference.
>>> >> >
>>> >> > I'm a bit of a loss.  I suppose I could try writing a simple test for
>>> >> > drmSetInterfaceVersion().  At least that should determine whether the
>>> >> > xserver/ddx is in the clear.
>>> >> >
>>> >> > Any other ideas?
>>> >> >
>>> >>
>>> >> Can you start a non-X runlevel and start X manually as root (assuming
>>> >> you are using a login manager now)?
>>> >>
>>> > My test program worked fine. I considerably improved it over the version 
>>> > I posted. I'll send it to the list when I get back.
>>> >
>>> > I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much 
>>> > further.  Starting Xserver as root  apparently started normally, 
>>> > according to the log, although  there was a permission denied error on 
>>> > mode set during init. I don't know whether it was related or not, but the 
>>> > display then hung with a non-blinking cursor. Strange to get a permission 
>>> > denied as root!
>>> >
>>> > Starting GNOME via gdm gives a working slow X session but for some reason 
>>> > only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. 
>>> > Perhaps it's a config error somewhere.. ?
>>> >
>>> > startx as a regular user just works!
>>> >
>>> > But mutter doesn't, perhaps that's
>>> > why a gnome session isn't working. It just gives the following error:
>>> > Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
>>> >
>>> > Mutter is supposed to work on r200, right?
>>>
>>> IIRC it tries to use a render buffer format that's not supported by the hw.
>> Is there anything to be done about it? Have to use a different wm/compositor?
>>
>
> Another wm or compositor may help.
>
>> Any idea why removing the call from radeon_kms.c worked?
>
> No idea.
>
>From a quick look at the actual implementation drmSetInterfaceVersion
is not something that we want/need to use with KMS drivers.

In general the original issue sound like the drm driver is not (fully)
loaded before the xserver/ddx kicks in. Additionally it may be a race
condition if something else (plymouth) is using the device. In the
latter case DRM_MASTER might still be held by $(other_app), thus
attempting to either SetInterfaceVersion or do any modeset operation
will fail.

Personally I would add a healthy amount of printk/printf though the
kernel drm + radeon and the ddx.

Cheers
Emil

[PATCH 2/2] drm/radeon: check if BO_VA is set before adding it to the invalidation list

[Michel Dänzer]

On 08.07.2015 16:56, Christian König wrote:
> From: Christian König 
> 
> Otherwise we try to clear BO_VAs without an address.
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91141
> 
> Signed-off-by: Christian König 
> Test-by: hadack at gmx.de

This series is

Tested-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH] drm: sti: add moduleparam to disable fbdev

[Daniel Vetter]

On Wed, Jul 08, 2015 at 02:50:25PM +0200, Benjamin Gaignard wrote:
> Useful to avoid recompiling to enable/disable fbdev.
> 
> Signed-off-by: Benjamin Gaignard 

Can we just do this in the fbdev helper instead of reinventing wheels in
each driver? Archit Taneja has been looking into that.

Thanks, Daniel

> ---
>  drivers/gpu/drm/sti/Kconfig   |  6 --
>  drivers/gpu/drm/sti/sti_drm_drv.c | 13 -
>  2 files changed, 8 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
> index fbccc10..e3aa5af 100644
> --- a/drivers/gpu/drm/sti/Kconfig
> +++ b/drivers/gpu/drm/sti/Kconfig
> @@ -9,9 +9,3 @@ config DRM_STI
>   select FW_LOADER_USER_HELPER_FALLBACK
>   help
> Choose this option to enable DRM on STM stiH41x chipset
> -
> -config DRM_STI_FBDEV
> - bool "DRM frame buffer device for STMicroelectronics SoC stiH41x Serie"
> - depends on DRM_STI
> - help
> -   Choose this option to enable FBDEV on top of DRM for STM stiH41x 
> chipset
> diff --git a/drivers/gpu/drm/sti/sti_drm_drv.c 
> b/drivers/gpu/drm/sti/sti_drm_drv.c
> index 59d558b..d0fb54a 100644
> --- a/drivers/gpu/drm/sti/sti_drm_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drm_drv.c
> @@ -30,6 +30,10 @@
>  #define STI_MAX_FB_HEIGHT4096
>  #define STI_MAX_FB_WIDTH 4096
>  
> +static bool fbdev;
> +MODULE_PARM_DESC(fbdev, "Enable fbdev compat layer");
> +module_param(fbdev, bool, S_IRUGO | S_IWUSR);
> +
>  static void sti_drm_atomic_schedule(struct sti_drm_private *private,
> struct drm_atomic_state *state)
>  {
> @@ -160,11 +164,10 @@ static int sti_drm_load(struct drm_device *dev, 
> unsigned long flags)
>  
>   drm_mode_config_reset(dev);
>  
> -#ifdef CONFIG_DRM_STI_FBDEV
> - drm_fbdev_cma_init(dev, 32,
> -dev->mode_config.num_crtc,
> -dev->mode_config.num_connector);
> -#endif
> + if (fbdev)
> + drm_fbdev_cma_init(dev, 32, dev->mode_config.num_crtc,
> +dev->mode_config.num_connector);
> +
>   return 0;
>  }
>  
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 01/10] i2c: add and export of_get_i2c_adapter_by_node() interface

[Vladimir Zapolskiy]

Hi Thierry,

On 08.07.2015 16:11, Thierry Reding wrote:
> On Wed, Jul 08, 2015 at 03:59:12PM +0300, Vladimir Zapolskiy wrote:
>> of_find_i2c_adapter_by_node() call requires quite often missing
>> put_device(), and i2c_put_adapter() releases a device locked by
>> i2c_get_adapter() only. In general module_put(adapter->owner) and
>> put_device(dev) are not interchangeable.
>>
>> This is a common error reproduction scenario as a result of the
>> misusage described above (for clearness this is run on iMX6 platform
>> with HDMI and I2C bus drivers compiled as kernel modules):
>>
>> root at mx6q:~# lsmod | grep i2c
>> i2c_imx10213  0
>> root at mx6q:~# lsmod | grep dw_hdmi_imx
>> dw_hdmi_imx 3631  0
>> dw_hdmi11846  1 dw_hdmi_imx
>> imxdrm  8674  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
>> drm_kms_helper113765  5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb
>> root at mx6q:~# rmmod dw_hdmi_imx
>> root at mx6q:~# lsmod | grep i2c
>> i2c_imx10213  -1
>>
>>  ^
>>
>> root at mx6q:~# rmmod i2c_imx
>> rmmod: ERROR: Module i2c_imx is in use
>>
>> To fix existing users of these interfaces and to avoid any further
>> confusion and misusage in future, add one more interface
>> of_get_i2c_adapter_by_node(), it is similar to i2c_get_adapter() in
>> sense that an I2C bus device driver found and locked by user can be
>> correctly unlocked by i2c_put_adapter().
>>
>> Signed-off-by: Vladimir Zapolskiy 
>> ---
>> The change is based on RFC 
>> http://www.spinics.net/lists/linux-i2c/msg20257.html
>>
>> * added new exported function declaration in include/linux/i2c.h
>> * added put_device(dev) call right inside of_get_i2c_adapter_by_node()
>> * corrected authorship of the change
>>
>>  drivers/i2c/i2c-core.c | 20 
>>  include/linux/i2c.h|  6 ++
>>  2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> index 069a41f..0d902ab 100644
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -1356,6 +1356,26 @@ struct i2c_adapter 
>> *of_find_i2c_adapter_by_node(struct device_node *node)
>>  return i2c_verify_adapter(dev);
>>  }
>>  EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
>> +
>> +struct i2c_adapter *of_get_i2c_adapter_by_node(struct device_node *node)
>> +{
>> +struct device *dev;
>> +struct i2c_adapter *adapter;
>> +
>> +dev = bus_find_device(_bus_type, NULL, node,
>> +  of_dev_node_match);
>> +if (!dev)
>> +return NULL;
>> +
>> +adapter = i2c_verify_adapter(dev);
>> +if (adapter && !try_module_get(adapter->owner))
>> +adapter = NULL;
>> +
>> +put_device(dev);
> 
> I don't think this is correct. Users still need to keep a reference to
> the device, otherwise it can simply disappear even if the module stays
> around (think sysfs bind/unbind attributes).
> 
> Looking at i2c_put_adapter() it seems like it would need to do more than
> just drop the module reference. Then again, that probably means that we
> need to add a get_device() somewhere in i2c_get_adapter() to balance the
> put_device() in i2c_put_adapter().

it makes sense for me, thanks for momentary review.

I'm hesitating to add put_device(dev) to i2c_put_adapter() etc. in this
series though. After development and testing I would like to send
another preceding independent change updating i2c_get_adapter(),
i2c_put_adapter() and clients (or if you wish you can do it), then I'll
rebase 01/10 on top of it, the rest most probably is unchanged.

--
With best wishes,
Vladimir

[PATCH 09/10] fbdev: omap2: connector-dvi: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

This change is needed to properly lock I2C bus driver, which serves DDC.

Prior to this change i2c_put_adapter() is misused, which may lead to
an overflow over zero of I2C bus driver user counter.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/video/fbdev/omap2/displays-new/connector-dvi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/displays-new/connector-dvi.c 
b/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
index a8ce920..d811e6d 100644
--- a/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/fbdev/omap2/displays-new/connector-dvi.c
@@ -294,7 +294,7 @@ static int dvic_probe_of(struct platform_device *pdev)

adapter_node = of_parse_phandle(node, "ddc-i2c-bus", 0);
if (adapter_node) {
-   adapter = of_find_i2c_adapter_by_node(adapter_node);
+   adapter = of_get_i2c_adapter_by_node(adapter_node);
if (adapter == NULL) {
dev_err(>dev, "failed to parse ddc-i2c-bus\n");
omap_dss_put_device(ddata->in);
-- 
2.1.4

[PATCH 08/10] drm: tilcdc: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

This change is needed to properly lock I2C bus driver, which serves DDC.

Prior to this change i2c_put_adapter() is misused, which may lead
to an overflow over zero of I2C bus driver user counter.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c 
b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
index 354c47c..4dc78c7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c
@@ -348,15 +348,13 @@ static int tfp410_probe(struct platform_device *pdev)
goto fail;
}

-   tfp410_mod->i2c = of_find_i2c_adapter_by_node(i2c_node);
+   tfp410_mod->i2c = of_get_i2c_adapter_by_node(i2c_node);
+   of_node_put(i2c_node);
if (!tfp410_mod->i2c) {
dev_err(>dev, "could not get i2c\n");
-   of_node_put(i2c_node);
goto fail;
}

-   of_node_put(i2c_node);
-
tfp410_mod->gpio = of_get_named_gpio_flags(node, "powerdn-gpio",
0, NULL);
if (IS_ERR_VALUE(tfp410_mod->gpio)) {
-- 
2.1.4

[PATCH 07/10] drm: tegra: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

This change is needed to properly lock I2C bus driver, which serves DDC.

On release of_get_i2c_adapter_by_node() requires i2c_put_adapter() call.

Note, that prior to the change put_device() coupled with
of_find_i2c_adapter_by_node() was missing on error path of
tegra_output_probe().

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/tegra/output.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 37db479..d7731cd 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -116,7 +116,7 @@ int tegra_output_probe(struct tegra_output *output)

ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
if (ddc) {
-   output->ddc = of_find_i2c_adapter_by_node(ddc);
+   output->ddc = of_get_i2c_adapter_by_node(ddc);
if (!output->ddc) {
err = -EPROBE_DEFER;
of_node_put(ddc);
@@ -136,14 +136,13 @@ int tegra_output_probe(struct tegra_output *output)
   "HDMI hotplug detect");
if (err < 0) {
dev_err(output->dev, "gpio_request_one(): %d\n", err);
-   return err;
+   goto i2c_release;
}

err = gpio_to_irq(output->hpd_gpio);
if (err < 0) {
dev_err(output->dev, "gpio_to_irq(): %d\n", err);
-   gpio_free(output->hpd_gpio);
-   return err;
+   goto gpio_release;
}

output->hpd_irq = err;
@@ -156,8 +155,7 @@ int tegra_output_probe(struct tegra_output *output)
if (err < 0) {
dev_err(output->dev, "failed to request IRQ#%u: %d\n",
output->hpd_irq, err);
-   gpio_free(output->hpd_gpio);
-   return err;
+   goto gpio_release;
}

output->connector.polled = DRM_CONNECTOR_POLL_HPD;
@@ -171,6 +169,12 @@ int tegra_output_probe(struct tegra_output *output)
}

return 0;
+
+ gpio_release:
+   gpio_free(output->hpd_gpio);
+ i2c_release:
+   i2c_put_adapter(output->ddc);
+   return err;
 }

 void tegra_output_remove(struct tegra_output *output)
@@ -180,8 +184,7 @@ void tegra_output_remove(struct tegra_output *output)
gpio_free(output->hpd_gpio);
}

-   if (output->ddc)
-   put_device(>ddc->dev);
+   i2c_put_adapter(output->ddc);
 }

 int tegra_output_init(struct drm_device *drm, struct tegra_output *output)
-- 
2.1.4

[PATCH 06/10] drm: sti_hdmi: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

This change is needed to properly lock I2C bus driver, which serves DDC.

On release of_get_i2c_adapter_by_node() requires i2c_put_adapter() call.

Note, that prior to the change put_device() coupled with
of_find_i2c_adapter_by_node() was incorrectly placed to sti_hdmi_remove()
instead of sti_hdmi_unbind().

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index f28a4d5..580a413 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -698,14 +698,10 @@ static int sti_hdmi_bind(struct device *dev, struct 
device *master, void *data)

ddc = of_parse_phandle(dev->of_node, "ddc", 0);
if (ddc) {
-   hdmi->ddc_adapt = of_find_i2c_adapter_by_node(ddc);
-   if (!hdmi->ddc_adapt) {
-   err = -EPROBE_DEFER;
-   of_node_put(ddc);
-   return err;
-   }
-
+   hdmi->ddc_adapt = of_get_i2c_adapter_by_node(ddc);
of_node_put(ddc);
+   if (!hdmi->ddc_adapt)
+   return -EPROBE_DEFER;
}

/* Set the drm device handle */
@@ -762,14 +758,15 @@ err_sysfs:
 err_connector:
drm_connector_cleanup(drm_connector);
 err_adapt:
-   put_device(>ddc_adapt->dev);
+   i2c_put_adapter(hdmi->ddc_adapt);
+
return -EINVAL;
 }

 static void sti_hdmi_unbind(struct device *dev,
struct device *master, void *data)
 {
-   /* do nothing */
+   i2c_put_adapter(hdmi->ddc_adapt);
 }

 static const struct component_ops sti_hdmi_ops = {
@@ -885,10 +882,8 @@ static int sti_hdmi_remove(struct platform_device *pdev)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(>dev);

-   if (hdmi->ddc_adapt)
-   put_device(>ddc_adapt->dev);
-
component_del(>dev, _hdmi_ops);
+
return 0;
 }

-- 
2.1.4

[PATCH 05/10] drm: panel-simple: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

This change is needed to properly lock I2C bus driver, which serves DDC.

On release of_get_i2c_adapter_by_node() requires i2c_put_adapter() call,
which replaces put_device().

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/panel/panel-simple.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b..b8a8b23 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -313,7 +313,7 @@ static int panel_simple_probe(struct device *dev, const 
struct panel_desc *desc)

ddc = of_parse_phandle(dev->of_node, "ddc-i2c-bus", 0);
if (ddc) {
-   panel->ddc = of_find_i2c_adapter_by_node(ddc);
+   panel->ddc = of_get_i2c_adapter_by_node(ddc);
of_node_put(ddc);

if (!panel->ddc) {
@@ -335,8 +335,8 @@ static int panel_simple_probe(struct device *dev, const 
struct panel_desc *desc)
return 0;

 free_ddc:
-   if (panel->ddc)
-   put_device(>ddc->dev);
+   i2c_put_adapter(panel->ddc);
+
 free_backlight:
if (panel->backlight)
put_device(>backlight->dev);
@@ -353,8 +353,7 @@ static int panel_simple_remove(struct device *dev)

panel_simple_disable(>base);

-   if (panel->ddc)
-   put_device(>ddc->dev);
+   i2c_put_adapter(panel->ddc);

if (panel->backlight)
put_device(>backlight->dev);
-- 
2.1.4

[PATCH 04/10] drm: imx-tve: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

This change is needed to properly lock I2C bus driver, which serves DDC.

Note that prior to this change put_device() coupled with
of_find_i2c_adapter_by_node() is missing on imx_tve_bind() error path
and imx_tve_unbind(), also the change fixes possibly left enabled voltage
regulator on imx_tve_bind() error path.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/imx/imx-tve.c | 56 +--
 1 file changed, 38 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 214ecee..f1ac927 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -581,14 +581,15 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)

ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
-   tve->ddc = of_find_i2c_adapter_by_node(ddc_node);
+   tve->ddc = of_get_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
}

tve->mode = of_get_tve_mode(np);
if (tve->mode != TVE_MODE_VGA) {
dev_err(dev, "only VGA mode supported, currently\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto i2c_release;
}

if (tve->mode == TVE_MODE_VGA) {
@@ -597,7 +598,7 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)

if (ret < 0) {
dev_err(dev, "failed to get vsync pin\n");
-   return ret;
+   goto i2c_release;
}

ret |= of_property_read_u32(np, "fsl,vsync-pin",
@@ -605,14 +606,16 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)

if (ret < 0) {
dev_err(dev, "failed to get vsync pin\n");
-   return ret;
+   goto i2c_release;
}
}

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   if (IS_ERR(base)) {
+   ret = PTR_ERR(base);
+   goto i2c_release;
+   }

tve_regmap_config.lock_arg = tve;
tve->regmap = devm_regmap_init_mmio_clk(dev, "tve", base,
@@ -620,13 +623,15 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)
if (IS_ERR(tve->regmap)) {
dev_err(dev, "failed to init regmap: %ld\n",
PTR_ERR(tve->regmap));
-   return PTR_ERR(tve->regmap);
+   ret = PTR_ERR(tve->regmap);
+   goto i2c_release;
}

irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(dev, "failed to get irq\n");
-   return irq;
+   ret = irq;
+   goto i2c_release;
}

ret = devm_request_threaded_irq(dev, irq, NULL,
@@ -634,7 +639,7 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)
"imx-tve", tve);
if (ret < 0) {
dev_err(dev, "failed to request irq: %d\n", ret);
-   return ret;
+   goto i2c_release;
}

tve->dac_reg = devm_regulator_get(dev, "dac");
@@ -642,14 +647,15 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)
regulator_set_voltage(tve->dac_reg, 275, 275);
ret = regulator_enable(tve->dac_reg);
if (ret)
-   return ret;
+   goto i2c_release;
}

tve->clk = devm_clk_get(dev, "tve");
if (IS_ERR(tve->clk)) {
dev_err(dev, "failed to get high speed tve clock: %ld\n",
PTR_ERR(tve->clk));
-   return PTR_ERR(tve->clk);
+   ret = PTR_ERR(tve->clk);
+   goto regulator_release;
}

/* this is the IPU DI clock input selector, can be parented to tve_di */
@@ -657,36 +663,48 @@ static int imx_tve_bind(struct device *dev, struct device 
*master, void *data)
if (IS_ERR(tve->di_sel_clk)) {
dev_err(dev, "failed to get ipu di mux clock: %ld\n",
PTR_ERR(tve->di_sel_clk));
-   return PTR_ERR(tve->di_sel_clk);
+   ret = PTR_ERR(tve->di_sel_clk);
+   goto regulator_release;
}

ret = tve_clk_init(tve, base);
if (ret < 0)
-   return ret;
+   goto regulator_release;

ret = regmap_read(tve->regmap, TVE_COM_CONF_REG, );
if (ret < 0) {
dev_err(dev, "failed to read configuration register: %d\n",
ret);
-   return ret;
+   goto regulator_release;
}
if (val != 

[PATCH 03/10] drm: exynos_hdmi: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

This change is needed to properly lock I2C bus driver, which serves DDC.

On release of_get_i2c_adapter_by_node() requires i2c_put_adapter() call,
which replaces put_device(). By the way added of_node_put(ddc_node) to
eliminate memory leak, if OF_DYNAMIC is enabled.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 99e2864..399eff9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2407,7 +2407,8 @@ static int hdmi_probe(struct platform_device *pdev)
}

 out_get_ddc_adpt:
-   hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
+   hdata->ddc_adpt = of_get_i2c_adapter_by_node(ddc_node);
+   of_node_put(ddc_node);
if (!hdata->ddc_adpt) {
DRM_ERROR("Failed to get ddc i2c adapter by node\n");
return -EPROBE_DEFER;
@@ -2485,7 +2486,7 @@ err_hdmiphy:
if (hdata->hdmiphy_port)
put_device(>hdmiphy_port->dev);
 err_ddc:
-   put_device(>ddc_adpt->dev);
+   i2c_put_adapter(hdata->ddc_adpt);

return ret;
 }
@@ -2501,7 +2502,7 @@ static int hdmi_remove(struct platform_device *pdev)

if (hdata->hdmiphy_port)
put_device(>hdmiphy_port->dev);
-   put_device(>ddc_adpt->dev);
+   i2c_put_adapter(hdata->ddc_adpt);

pm_runtime_disable(>dev);
component_del(>dev, _component_ops);
-- 
2.1.4

[PATCH 02/10] drm: dw_hdmi: use of_get_i2c_adapter_by_node interface

[Vladimir Zapolskiy]

This change is needed to properly lock I2C bus driver, which serves DDC.

The change fixes an overflow over zero of I2C bus driver user counter:

root at mx6q:~# lsmod | grep i2c
i2c_imx10213  0
root at mx6q:~# lsmod | grep dw_hdmi_imx
dw_hdmi_imx 3631  0
dw_hdmi11846  1 dw_hdmi_imx
imxdrm  8674  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
drm_kms_helper113765  5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb
root at mx6q:~# rmmod dw_hdmi_imx
root at mx6q:~# lsmod | grep i2c
i2c_imx10213  -1

 ^

root at mx6q:~# rmmod i2c_imx
rmmod: ERROR: Module i2c_imx is in use

Note that prior to this change put_device() coupled with
of_find_i2c_adapter_by_node() was missing on error path of
dw_hdmi_bind(), added i2c_put_adapter() there along with the change.

Signed-off-by: Vladimir Zapolskiy 
---
 drivers/gpu/drm/bridge/dw_hdmi.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 816d104..e86776c 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -1591,7 +1591,7 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,

ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
-   hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
+   hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
if (!hdmi->ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
@@ -1603,20 +1603,22 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,
}

hdmi->regs = devm_ioremap_resource(dev, iores);
-   if (IS_ERR(hdmi->regs))
-   return PTR_ERR(hdmi->regs);
+   if (IS_ERR(hdmi->regs)) {
+   ret = PTR_ERR(hdmi->regs);
+   goto err_res;
+   }

hdmi->isfr_clk = devm_clk_get(hdmi->dev, "isfr");
if (IS_ERR(hdmi->isfr_clk)) {
ret = PTR_ERR(hdmi->isfr_clk);
dev_err(hdmi->dev, "Unable to get HDMI isfr clk: %d\n", ret);
-   return ret;
+   goto err_res;
}

ret = clk_prepare_enable(hdmi->isfr_clk);
if (ret) {
dev_err(hdmi->dev, "Cannot enable HDMI isfr clock: %d\n", ret);
-   return ret;
+   goto err_res;
}

hdmi->iahb_clk = devm_clk_get(hdmi->dev, "iahb");
@@ -1682,6 +1684,8 @@ err_iahb:
clk_disable_unprepare(hdmi->iahb_clk);
 err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
+err_res:
+   i2c_put_adapter(hdmi->ddc);

return ret;
 }
-- 
2.1.4

[PATCH 01/10] i2c: add and export of_get_i2c_adapter_by_node() interface

[Vladimir Zapolskiy]

of_find_i2c_adapter_by_node() call requires quite often missing
put_device(), and i2c_put_adapter() releases a device locked by
i2c_get_adapter() only. In general module_put(adapter->owner) and
put_device(dev) are not interchangeable.

This is a common error reproduction scenario as a result of the
misusage described above (for clearness this is run on iMX6 platform
with HDMI and I2C bus drivers compiled as kernel modules):

root at mx6q:~# lsmod | grep i2c
i2c_imx10213  0
root at mx6q:~# lsmod | grep dw_hdmi_imx
dw_hdmi_imx 3631  0
dw_hdmi11846  1 dw_hdmi_imx
imxdrm  8674  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
drm_kms_helper113765  5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb
root at mx6q:~# rmmod dw_hdmi_imx
root at mx6q:~# lsmod | grep i2c
i2c_imx10213  -1

 ^

root at mx6q:~# rmmod i2c_imx
rmmod: ERROR: Module i2c_imx is in use

To fix existing users of these interfaces and to avoid any further
confusion and misusage in future, add one more interface
of_get_i2c_adapter_by_node(), it is similar to i2c_get_adapter() in
sense that an I2C bus device driver found and locked by user can be
correctly unlocked by i2c_put_adapter().

Signed-off-by: Vladimir Zapolskiy 
---
The change is based on RFC http://www.spinics.net/lists/linux-i2c/msg20257.html

* added new exported function declaration in include/linux/i2c.h
* added put_device(dev) call right inside of_get_i2c_adapter_by_node()
* corrected authorship of the change

 drivers/i2c/i2c-core.c | 20 
 include/linux/i2c.h|  6 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 069a41f..0d902ab 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1356,6 +1356,26 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
device_node *node)
return i2c_verify_adapter(dev);
 }
 EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
+
+struct i2c_adapter *of_get_i2c_adapter_by_node(struct device_node *node)
+{
+   struct device *dev;
+   struct i2c_adapter *adapter;
+
+   dev = bus_find_device(_bus_type, NULL, node,
+ of_dev_node_match);
+   if (!dev)
+   return NULL;
+
+   adapter = i2c_verify_adapter(dev);
+   if (adapter && !try_module_get(adapter->owner))
+   adapter = NULL;
+
+   put_device(dev);
+
+   return adapter;
+}
+EXPORT_SYMBOL(of_get_i2c_adapter_by_node);
 #else
 static void of_i2c_register_devices(struct i2c_adapter *adap) { }
 #endif /* CONFIG_OF */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index e83a738..87bb217 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -638,6 +638,7 @@ extern struct i2c_client *of_find_i2c_device_by_node(struct 
device_node *node);
 /* must call put_device() when done with returned i2c_adapter device */
 extern struct i2c_adapter *of_find_i2c_adapter_by_node(struct device_node 
*node);

+struct i2c_adapter *of_get_i2c_adapter_by_node(struct device_node *node);
 #else

 static inline struct i2c_client *of_find_i2c_device_by_node(struct device_node 
*node)
@@ -649,6 +650,11 @@ static inline struct i2c_adapter 
*of_find_i2c_adapter_by_node(struct device_node
 {
return NULL;
 }
+
+static inline struct i2c_adapter *of_get_i2c_adapter_by_node(struct 
device_node *node)
+{
+   return NULL;
+}
 #endif /* CONFIG_OF */

 #endif /* _LINUX_I2C_H */
-- 
2.1.4

[PATCH 00/10] i2c/drm: fix i2c adapter device driver user counter

[Vladimir Zapolskiy]

The 01/10 change adds and exports new of_get_i2c_adapter_by_node()
interface of i2c core, the rest of patches fix current users of
of_find_i2c_adapter_by_node() interface.

of_find_i2c_adapter_by_node() call requires quite often missing
put_device(), and i2c_put_adapter() releases a device locked by
i2c_get_adapter() only. In general module_put(adapter->owner) and
put_device(dev) are not interchangeable.

This is a common error reproduction scenario as a result of the
misusage described above (this is run on iMX6 platform with
HDMI and I2C bus drivers compiled as kernel modules for clearness):

root at mx6q:~# lsmod | grep i2c
i2c_imx10213  0
root at mx6q:~# lsmod | grep dw_hdmi_imx
dw_hdmi_imx 3631  0
dw_hdmi11846  1 dw_hdmi_imx
imxdrm  8674  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
drm_kms_helper113765  5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb
root at mx6q:~# rmmod dw_hdmi_imx
root at mx6q:~# lsmod | grep i2c
i2c_imx10213  -1

 ^

root at mx6q:~# rmmod i2c_imx
rmmod: ERROR: Module i2c_imx is in use

To fix existing users of these interfaces and to avoid any further
confusion and misusage in future, add one more interface
of_get_i2c_adapter_by_node(), it is similar to i2c_get_adapter() in
sense that an I2C bus device driver found and locked by user can be
correctly unlocked by i2c_put_adapter().

Mainly the change concerns DRM users of I2C bus device.

The change is based on torvalds/master branch, d6ac4ffc61a

RFC of the 01/10 change is http://www.spinics.net/lists/linux-i2c/msg20257.html

Vladimir Zapolskiy (10):
  i2c: add and export of_get_i2c_adapter_by_node() interface
  drm: dw_hdmi: use of_get_i2c_adapter_by_node interface
  drm: exynos_hdmi: use of_get_i2c_adapter_by_node interface
  drm: imx-tve: use of_get_i2c_adapter_by_node interface
  drm: panel-simple: use of_get_i2c_adapter_by_node interface
  drm: sti_hdmi: use of_get_i2c_adapter_by_node interface
  drm: tegra: use of_get_i2c_adapter_by_node interface
  drm: tilcdc: use of_get_i2c_adapter_by_node interface
  fbdev: omap2: connector-dvi: use of_get_i2c_adapter_by_node interface
  i2c: i2c-arb-gpio-challenge: use of_get_i2c_adapter_by_node interface

 drivers/gpu/drm/bridge/dw_hdmi.c   | 14 --
 drivers/gpu/drm/exynos/exynos_hdmi.c   |  7 +--
 drivers/gpu/drm/imx/imx-tve.c  | 56 +++---
 drivers/gpu/drm/panel/panel-simple.c   |  9 ++--
 drivers/gpu/drm/sti/sti_hdmi.c | 19 +++-
 drivers/gpu/drm/tegra/output.c | 19 
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  6 +--
 drivers/i2c/i2c-core.c | 20 
 drivers/i2c/muxes/i2c-arb-gpio-challenge.c |  3 +-
 .../video/fbdev/omap2/displays-new/connector-dvi.c |  2 +-
 include/linux/i2c.h|  6 +++
 11 files changed, 104 insertions(+), 57 deletions(-)

-- 
2.1.4

[PATCH 01/10] i2c: add and export of_get_i2c_adapter_by_node() interface

[Thierry Reding]

On Wed, Jul 08, 2015 at 04:31:37PM +0300, Vladimir Zapolskiy wrote:
> Hi Thierry,
> 
> On 08.07.2015 16:11, Thierry Reding wrote:
> > On Wed, Jul 08, 2015 at 03:59:12PM +0300, Vladimir Zapolskiy wrote:
> >> of_find_i2c_adapter_by_node() call requires quite often missing
> >> put_device(), and i2c_put_adapter() releases a device locked by
> >> i2c_get_adapter() only. In general module_put(adapter->owner) and
> >> put_device(dev) are not interchangeable.
> >>
> >> This is a common error reproduction scenario as a result of the
> >> misusage described above (for clearness this is run on iMX6 platform
> >> with HDMI and I2C bus drivers compiled as kernel modules):
> >>
> >> root at mx6q:~# lsmod | grep i2c
> >> i2c_imx10213  0
> >> root at mx6q:~# lsmod | grep dw_hdmi_imx
> >> dw_hdmi_imx 3631  0
> >> dw_hdmi11846  1 dw_hdmi_imx
> >> imxdrm  8674  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
> >> drm_kms_helper113765  5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb
> >> root at mx6q:~# rmmod dw_hdmi_imx
> >> root at mx6q:~# lsmod | grep i2c
> >> i2c_imx10213  -1
> >>
> >>  ^
> >>
> >> root at mx6q:~# rmmod i2c_imx
> >> rmmod: ERROR: Module i2c_imx is in use
> >>
> >> To fix existing users of these interfaces and to avoid any further
> >> confusion and misusage in future, add one more interface
> >> of_get_i2c_adapter_by_node(), it is similar to i2c_get_adapter() in
> >> sense that an I2C bus device driver found and locked by user can be
> >> correctly unlocked by i2c_put_adapter().
> >>
> >> Signed-off-by: Vladimir Zapolskiy 
> >> ---
> >> The change is based on RFC 
> >> http://www.spinics.net/lists/linux-i2c/msg20257.html
> >>
> >> * added new exported function declaration in include/linux/i2c.h
> >> * added put_device(dev) call right inside of_get_i2c_adapter_by_node()
> >> * corrected authorship of the change
> >>
> >>  drivers/i2c/i2c-core.c | 20 
> >>  include/linux/i2c.h|  6 ++
> >>  2 files changed, 26 insertions(+)
> >>
> >> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> >> index 069a41f..0d902ab 100644
> >> --- a/drivers/i2c/i2c-core.c
> >> +++ b/drivers/i2c/i2c-core.c
> >> @@ -1356,6 +1356,26 @@ struct i2c_adapter 
> >> *of_find_i2c_adapter_by_node(struct device_node *node)
> >>return i2c_verify_adapter(dev);
> >>  }
> >>  EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
> >> +
> >> +struct i2c_adapter *of_get_i2c_adapter_by_node(struct device_node *node)
> >> +{
> >> +  struct device *dev;
> >> +  struct i2c_adapter *adapter;
> >> +
> >> +  dev = bus_find_device(_bus_type, NULL, node,
> >> +of_dev_node_match);
> >> +  if (!dev)
> >> +  return NULL;
> >> +
> >> +  adapter = i2c_verify_adapter(dev);
> >> +  if (adapter && !try_module_get(adapter->owner))
> >> +  adapter = NULL;
> >> +
> >> +  put_device(dev);
> > 
> > I don't think this is correct. Users still need to keep a reference to
> > the device, otherwise it can simply disappear even if the module stays
> > around (think sysfs bind/unbind attributes).
> > 
> > Looking at i2c_put_adapter() it seems like it would need to do more than
> > just drop the module reference. Then again, that probably means that we
> > need to add a get_device() somewhere in i2c_get_adapter() to balance the
> > put_device() in i2c_put_adapter().
> 
> it makes sense for me, thanks for momentary review.
> 
> I'm hesitating to add put_device(dev) to i2c_put_adapter() etc. in this
> series though. After development and testing I would like to send
> another preceding independent change updating i2c_get_adapter(),
> i2c_put_adapter() and clients (or if you wish you can do it), then I'll
> rebase 01/10 on top of it, the rest most probably is unchanged.

I think that would make sense, yes.

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/20150708/06f627f2/attachment.sig>

[PATCH] drm/radeon: disable vce init on cayman (v2)

[Alex Deucher]

Cayman does not have vce.  There were a few places in the
shared cayman/TV code where we were trying to do vce stuff.

v2: remove -ENOENT check

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ni.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 8e5aeeb..158872e 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2162,18 +2162,20 @@ static int cayman_startup(struct radeon_device *rdev)
DRM_ERROR("radeon: failed initializing UVD (%d).\n", r);
}

-   ring = >ring[TN_RING_TYPE_VCE1_INDEX];
-   if (ring->ring_size)
-   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
+   if (rdev->family == CHIP_ARUBA) {
+   ring = >ring[TN_RING_TYPE_VCE1_INDEX];
+   if (ring->ring_size)
+   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 
0x0);

-   ring = >ring[TN_RING_TYPE_VCE2_INDEX];
-   if (ring->ring_size)
-   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
+   ring = >ring[TN_RING_TYPE_VCE2_INDEX];
+   if (ring->ring_size)
+   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 
0x0);

-   if (!r)
-   r = vce_v1_0_init(rdev);
-   else if (r != -ENOENT)
-   DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
+   if (!r)
+   r = vce_v1_0_init(rdev);
+   if (r)
+   DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
+   }

r = radeon_ib_pool_init(rdev);
if (r) {
@@ -2396,7 +2398,8 @@ void cayman_fini(struct radeon_device *rdev)
radeon_irq_kms_fini(rdev);
uvd_v1_0_fini(rdev);
radeon_uvd_fini(rdev);
-   radeon_vce_fini(rdev);
+   if (rdev->family == CHIP_ARUBA)
+   radeon_vce_fini(rdev);
cayman_pcie_gart_fini(rdev);
r600_vram_scratch_fini(rdev);
radeon_gem_fini(rdev);
-- 
1.8.3.1

[PATCH 01/10] i2c: add and export of_get_i2c_adapter_by_node() interface

[Thierry Reding]

On Wed, Jul 08, 2015 at 03:59:12PM +0300, Vladimir Zapolskiy wrote:
> of_find_i2c_adapter_by_node() call requires quite often missing
> put_device(), and i2c_put_adapter() releases a device locked by
> i2c_get_adapter() only. In general module_put(adapter->owner) and
> put_device(dev) are not interchangeable.
> 
> This is a common error reproduction scenario as a result of the
> misusage described above (for clearness this is run on iMX6 platform
> with HDMI and I2C bus drivers compiled as kernel modules):
> 
> root at mx6q:~# lsmod | grep i2c
> i2c_imx10213  0
> root at mx6q:~# lsmod | grep dw_hdmi_imx
> dw_hdmi_imx 3631  0
> dw_hdmi11846  1 dw_hdmi_imx
> imxdrm  8674  3 dw_hdmi_imx,imx_ipuv3_crtc,imx_ldb
> drm_kms_helper113765  5 dw_hdmi,imxdrm,imx_ipuv3_crtc,imx_ldb
> root at mx6q:~# rmmod dw_hdmi_imx
> root at mx6q:~# lsmod | grep i2c
> i2c_imx10213  -1
> 
>  ^
> 
> root at mx6q:~# rmmod i2c_imx
> rmmod: ERROR: Module i2c_imx is in use
> 
> To fix existing users of these interfaces and to avoid any further
> confusion and misusage in future, add one more interface
> of_get_i2c_adapter_by_node(), it is similar to i2c_get_adapter() in
> sense that an I2C bus device driver found and locked by user can be
> correctly unlocked by i2c_put_adapter().
> 
> Signed-off-by: Vladimir Zapolskiy 
> ---
> The change is based on RFC 
> http://www.spinics.net/lists/linux-i2c/msg20257.html
> 
> * added new exported function declaration in include/linux/i2c.h
> * added put_device(dev) call right inside of_get_i2c_adapter_by_node()
> * corrected authorship of the change
> 
>  drivers/i2c/i2c-core.c | 20 
>  include/linux/i2c.h|  6 ++
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 069a41f..0d902ab 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -1356,6 +1356,26 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct 
> device_node *node)
>   return i2c_verify_adapter(dev);
>  }
>  EXPORT_SYMBOL(of_find_i2c_adapter_by_node);
> +
> +struct i2c_adapter *of_get_i2c_adapter_by_node(struct device_node *node)
> +{
> + struct device *dev;
> + struct i2c_adapter *adapter;
> +
> + dev = bus_find_device(_bus_type, NULL, node,
> +   of_dev_node_match);
> + if (!dev)
> + return NULL;
> +
> + adapter = i2c_verify_adapter(dev);
> + if (adapter && !try_module_get(adapter->owner))
> + adapter = NULL;
> +
> + put_device(dev);

I don't think this is correct. Users still need to keep a reference to
the device, otherwise it can simply disappear even if the module stays
around (think sysfs bind/unbind attributes).

Looking at i2c_put_adapter() it seems like it would need to do more than
just drop the module reference. Then again, that probably means that we
need to add a get_device() somewhere in i2c_get_adapter() to balance the
put_device() in i2c_put_adapter().

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/20150708/212be892/attachment.sig>

[PATCH 1/2] drm/radeon: allways add the VM clear duplicate

[Alex Deucher]

On Wed, Jul 8, 2015 at 2:28 PM, Christian König  
wrote:
> On 08.07.2015 18:33, Alex Deucher wrote:
>>
>> On Wed, Jul 8, 2015 at 12:31 PM, Christian König
>>  wrote:
>>>
>>> On 08.07.2015 18:14, Alex Deucher wrote:

 On Wed, Jul 8, 2015 at 12:08 PM, Christian König
  wrote:
>
> On 08.07.2015 17:57, Alex Deucher wrote:
>>
>> On Wed, Jul 8, 2015 at 3:56 AM, Christian König
>> 
>> wrote:
>>>
>>> From: Christian König 
>>>
>>> We need to allways add the VM clear duplicate of the BO_VA,
>>> no matter what the old status was.
>>>
>>> Signed-off-by: Christian König 
>>> Test-by: hadack at gmx.de
>>
>> This patch does not apply cleanly.  It also adds an undefined label
>> error_unreserve.  Is there an additional patch required?
>
>
> That's possible, but I thought the depending patch would have already
> been
> upstream.
>
> Can you create a drm-fixes-4.2 branch I can rebase on?

 http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.2-wip
>>>
>>>
>>> Ah, here is the problem. This branch don't yet contains the fixes which
>>> went
>>> upstream with 4.1.
>>>
>>> What should we do? I don't want to change those patches and create a
>>> merge
>>> conflict when you merge in 4.1.
>>
>> I'll rebase by tree on Linus' tree.  Dave is on vacation so his tree is
>> lagging.
>
>
> Sounds good, let me know when you have updated the branch and there are
> still conflicts.

All set.

Thanks,

Alex

>
> Regards,
> Christian.
>
>
>>
>> Alex
>>
>>> Christian.
>>>
>>>
 Thanks,

 Alex

> Thanks,
> Christian.
>
>
>> Alex
>>
>>> ---
>>> drivers/gpu/drm/radeon/radeon_vm.c | 34
>>> --
>>> 1 file changed, 16 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
>>> b/drivers/gpu/drm/radeon/radeon_vm.c
>>> index ec10533..0310965 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_vm.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
>>> @@ -493,29 +493,27 @@ int radeon_vm_bo_set_addr(struct radeon_device
>>> *rdev,
>>>}
>>>
>>>if (bo_va->it.start || bo_va->it.last) {
>>> -   spin_lock(>status_lock);
>>> -   if (list_empty(_va->vm_status)) {
>>> -   /* add a clone of the bo_va to clear the old
>>> address */
>>> -   struct radeon_bo_va *tmp;
>>> -   spin_unlock(>status_lock);
>>> -   tmp = kzalloc(sizeof(struct radeon_bo_va),
>>> GFP_KERNEL);
>>> -   if (!tmp) {
>>> -   mutex_unlock(>mutex);
>>> -   r = -ENOMEM;
>>> -   goto error_unreserve;
>>> -   }
>>> -   tmp->it.start = bo_va->it.start;
>>> -   tmp->it.last = bo_va->it.last;
>>> -   tmp->vm = vm;
>>> -   tmp->bo = radeon_bo_ref(bo_va->bo);
>>> -   spin_lock(>status_lock);
>>> -   list_add(>vm_status, >freed);
>>> +   /* add a clone of the bo_va to clear the old address
>>> */
>>> +   struct radeon_bo_va *tmp;
>>> +   tmp = kzalloc(sizeof(struct radeon_bo_va),
>>> GFP_KERNEL);
>>> +   if (!tmp) {
>>> +   mutex_unlock(>mutex);
>>> +   r = -ENOMEM;
>>> +   goto error_unreserve;
>>>}
>>> -   spin_unlock(>status_lock);
>>> +   tmp->it.start = bo_va->it.start;
>>> +   tmp->it.last = bo_va->it.last;
>>> +   tmp->vm = vm;
>>> +   tmp->bo = radeon_bo_ref(bo_va->bo);
>>>
>>>interval_tree_remove(_va->it, >va);
>>>bo_va->it.start = 0;
>>>bo_va->it.last = 0;
>>> +
>>> +   spin_lock(>status_lock);
>>> +   list_del_init(_va->vm_status);
>>> +   list_add(>vm_status, >freed);
>>> +   spin_unlock(>status_lock);
>>>}
>>>
>>>if (soffset || eoffset) {
>>> --
>>> 1.9.1
>>>
>

Skip cache sync for GEM CMA objects?

[Steve Longerbeam]

Hi all,

GEM CMA uses dma_alloc_writecombine() when allocating the CMA objects.
So IINM the GEM buffers are cache coherent. So is there any reason why
DMA_ATTR_SKIP_CPU_SYNC is not passed to dma_map_sg() when GEM CMA
prepares the buffer for dma on behalf of the dma-buf user? Is this just an
oversight or is there something I have missed?

Thanks,
Steve

Skip cache sync for GEM CMA objects?

[Steve Longerbeam]

Hi all,

GEM CMA uses dma_alloc_writecombine() when allocating the CMA objects.
So IINM the GEM buffers are cache coherent. So is there any reason why
DMA_ATTR_SKIP_CPU_SYNC is not passed to dma_map_sg() when GEM CMA
prepares the buffer for dma on behalf of the dma-buf user? Is this just an
oversight or is there something I have missed?

Thanks,
Steve

[PATCH] drm: sti: add moduleparam to disable fbdev

[Benjamin Gaignard]

Useful to avoid recompiling to enable/disable fbdev.

Signed-off-by: Benjamin Gaignard 
---
 drivers/gpu/drm/sti/Kconfig   |  6 --
 drivers/gpu/drm/sti/sti_drm_drv.c | 13 -
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index fbccc10..e3aa5af 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -9,9 +9,3 @@ config DRM_STI
select FW_LOADER_USER_HELPER_FALLBACK
help
  Choose this option to enable DRM on STM stiH41x chipset
-
-config DRM_STI_FBDEV
-   bool "DRM frame buffer device for STMicroelectronics SoC stiH41x Serie"
-   depends on DRM_STI
-   help
- Choose this option to enable FBDEV on top of DRM for STM stiH41x 
chipset
diff --git a/drivers/gpu/drm/sti/sti_drm_drv.c 
b/drivers/gpu/drm/sti/sti_drm_drv.c
index 59d558b..d0fb54a 100644
--- a/drivers/gpu/drm/sti/sti_drm_drv.c
+++ b/drivers/gpu/drm/sti/sti_drm_drv.c
@@ -30,6 +30,10 @@
 #define STI_MAX_FB_HEIGHT  4096
 #define STI_MAX_FB_WIDTH   4096

+static bool fbdev;
+MODULE_PARM_DESC(fbdev, "Enable fbdev compat layer");
+module_param(fbdev, bool, S_IRUGO | S_IWUSR);
+
 static void sti_drm_atomic_schedule(struct sti_drm_private *private,
  struct drm_atomic_state *state)
 {
@@ -160,11 +164,10 @@ static int sti_drm_load(struct drm_device *dev, unsigned 
long flags)

drm_mode_config_reset(dev);

-#ifdef CONFIG_DRM_STI_FBDEV
-   drm_fbdev_cma_init(dev, 32,
-  dev->mode_config.num_crtc,
-  dev->mode_config.num_connector);
-#endif
+   if (fbdev)
+   drm_fbdev_cma_init(dev, 32, dev->mode_config.num_crtc,
+  dev->mode_config.num_connector);
+
return 0;
 }

-- 
1.9.1

[PATCH 1/2] drm/ttm: fix object deallocation to properly fill in the page pool.

[Konrad Rzeszutek Wilk]

On Wed, Jul 08, 2015 at 02:16:36PM -0400, j.glisse at gmail.com wrote:
> From: Jérôme Glisse 
> 
> Current code never allowed the page pool to actualy fill in anyway.
> This fix it, so that we only start freeing page from the pool when
> we go over the pool size.
> 
> Signed-off-by: Jérôme Glisse 
> Reviewed-by: Mario Kleiner 
> Tested-by: Michel Dänzer 
> Cc: Thomas Hellstrom 
> Cc: Konrad Rzeszutek Wilk 

Reviewed-by: Konrad Rzeszutek Wilk 

> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index c96db43..0194a93 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -953,14 +953,8 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
> struct device *dev)
>   } else {
>   pool->npages_free += count;
>   list_splice(_dma->pages_list, >free_list);
> - npages = count;
> - if (pool->npages_free > _manager->options.max_size) {
> + if (pool->npages_free > _manager->options.max_size)
>   npages = pool->npages_free - _manager->options.max_size;
> - /* free at least NUM_PAGES_TO_ALLOC number of pages
> -  * to reduce calls to set_memory_wb */
> - if (npages < NUM_PAGES_TO_ALLOC)
> - npages = NUM_PAGES_TO_ALLOC;
> - }
>   }
>   spin_unlock_irqrestore(>lock, irq_flags);
>  
> -- 
> 1.8.3.1
> 

[PATCH 2/2] drm/ttm: improve uncached page deallocation.

[Konrad Rzeszutek Wilk]

On Wed, Jul 08, 2015 at 02:16:37PM -0400, j.glisse at gmail.com wrote:
> From: Jérôme Glisse 
> 
> Calls to set_memory_wb() incure heavy TLB flush and IPI cost. To
> minimize those wait until pool grow beyond batch size before
> draining the pool.
> 
> Signed-off-by: Jérôme Glisse 
> Reviewed-by: Mario Kleiner 
> Cc: Michel Dänzer 
> Cc: Thomas Hellstrom 
> Cc: Konrad Rzeszutek Wilk 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index 0194a93..8028dd6 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -953,7 +953,12 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, 
> struct device *dev)
>   } else {
>   pool->npages_free += count;
>   list_splice(_dma->pages_list, >free_list);
> - if (pool->npages_free > _manager->options.max_size)
> + /*
> +  * Wait to have at at least NUM_PAGES_TO_ALLOC number of pages
> +  * to free in order to minimize calls to set_memory_wb().
> +  */
> + if (pool->npages_free >= (_manager->options.max_size +
> +   NUM_PAGES_TO_ALLOC))
>   npages = pool->npages_free - _manager->options.max_size;
>   }
>   spin_unlock_irqrestore(>lock, irq_flags);
> -- 
> 1.8.3.1
> 

[PATCH 5/5] drm/tegra: Add Tegra DRM allocation API

[Mikko Perttunen]

Add a new IO virtual memory allocation API to allow clients to
allocate non-GEM memory in the Tegra DRM IOMMU domain. This is
required e.g. for loading client firmware when clients are attached
to the IOMMU domain.

The allocator allocates contiguous physical pages that are then
mapped contiguously to the IOMMU domain using a bitmap allocator
inside a 64 MiB reserved for non-GEM allocations. Contiguous
physical pages are used so that the same allocator works also
when IOMMU support is disabled and therefore devices access
physical memory directly.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/drm.c | 99 ++---
 drivers/gpu/drm/tegra/drm.h |  9 +
 2 files changed, 103 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 427f50c..af4ff86 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1,12 +1,13 @@
 /*
  * Copyright (C) 2012 Avionic Design GmbH
- * Copyright (C) 2012-2013 NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (C) 2012-2015 NVIDIA CORPORATION.  All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */

+#include 
 #include 
 #include 

@@ -23,6 +24,8 @@
 #define DRIVER_MINOR 0
 #define DRIVER_PATCHLEVEL 0

+#define IOVA_AREA_SZ (1024 * 1024 * 64) /* 64 MiB */
+
 struct tegra_drm_file {
struct list_head contexts;
 };
@@ -125,7 +128,8 @@ static int tegra_drm_load(struct drm_device *drm, unsigned 
long flags)

if (iommu_present(_bus_type)) {
struct iommu_domain_geometry *geometry;
-   u64 start, end;
+   u64 start, end, iova_start;
+   size_t bitmap_size;

tegra->domain = iommu_domain_alloc(_bus_type);
if (!tegra->domain) {
@@ -136,10 +140,23 @@ static int tegra_drm_load(struct drm_device *drm, 
unsigned long flags)
geometry = >domain->geometry;
start = geometry->aperture_start;
end = geometry->aperture_end;
+   iova_start = end - IOVA_AREA_SZ + 1;
+
+   DRM_DEBUG("IOMMU context initialized (GEM aperture: 
%#llx-%#llx, IOVA aperture: %#llx-%#llx)\n",
+ start, iova_start-1, iova_start, end);
+   bitmap_size = BITS_TO_LONGS(IOVA_AREA_SZ >> PAGE_SHIFT) *
+   sizeof(long);
+   tegra->iova_bitmap = devm_kzalloc(drm->dev, bitmap_size,
+ GFP_KERNEL);
+   if (!tegra->iova_bitmap) {
+   err = -ENOMEM;
+   goto free;
+   }
+   tegra->iova_bitmap_bits = BITS_PER_BYTE * bitmap_size;
+   tegra->iova_start = iova_start;
+   mutex_init(>iova_lock);

-   DRM_DEBUG("IOMMU context initialized (aperture: %#llx-%#llx)\n",
- start, end);
-   drm_mm_init(>mm, start, end - start + 1);
+   drm_mm_init(>mm, start, iova_start - start);
}

mutex_init(>clients_lock);
@@ -979,6 +996,78 @@ int tegra_drm_unregister_client(struct tegra_drm *tegra,
return 0;
 }

+void *tegra_drm_alloc(struct tegra_drm *tegra, size_t size,
+ dma_addr_t *iova)
+{
+   size_t aligned = PAGE_ALIGN(size);
+   int num_pages = aligned >> PAGE_SHIFT;
+   void *virt;
+   unsigned int start;
+   int err;
+
+   virt = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
+   get_order(aligned));
+   if (!virt)
+   return NULL;
+
+   if (!tegra->domain) {
+   /*
+* If IOMMU is disabled, devices address physical memory
+* directly.
+*/
+   *iova = virt_to_phys(virt);
+   return virt;
+   }
+
+   mutex_lock(>iova_lock);
+
+   start = bitmap_find_next_zero_area(tegra->iova_bitmap,
+  tegra->iova_bitmap_bits, 0,
+  num_pages, 0);
+   if (start > tegra->iova_bitmap_bits)
+   goto free_pages;
+
+   bitmap_set(tegra->iova_bitmap, start, num_pages);
+
+   *iova = tegra->iova_start + (start << PAGE_SHIFT);
+   err = iommu_map(tegra->domain, *iova, virt_to_phys(virt),
+   aligned, IOMMU_READ | IOMMU_WRITE);
+   if (err < 0)
+   goto free_iova;
+
+   mutex_unlock(>iova_lock);
+
+   return virt;
+
+free_iova:
+   bitmap_clear(tegra->iova_bitmap, start, num_pages);
+free_pages:
+   mutex_unlock(>iova_lock);
+
+   free_pages((unsigned long)virt, get_order(aligned));
+
+   return NULL;
+}
+
+void tegra_drm_free(struct tegra_drm *tegra, size_t 

[PATCH 4/5] drm/tegra: Support kernel mappings with IOMMU

[Mikko Perttunen]

From: Arto Merilainen 

Host1x command buffer patching requires that the buffer object can be
mapped into kernel address space, however, the recent addition of
IOMMU did not account to this requirement. Therefore Host1x engines
cannot be used if IOMMU is enabled.

This patch implements kmap, kunmap, mmap and munmap functions to
host1x bo objects.

Signed-off-by: Arto Merilainen 
Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/gem.c | 34 +++---
 1 file changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 01e16e1..6aed866 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -2,7 +2,7 @@
  * NVIDIA Tegra DRM GEM helper functions
  *
  * Copyright (C) 2012 Sascha Hauer, Pengutronix
- * Copyright (C) 2013 NVIDIA CORPORATION, All rights reserved.
+ * Copyright (C) 2013-2015 NVIDIA CORPORATION, All rights reserved.
  *
  * Based on the GEM/CMA helpers
  *
@@ -50,23 +50,51 @@ static void *tegra_bo_mmap(struct host1x_bo *bo)
 {
struct tegra_bo *obj = host1x_to_tegra_bo(bo);

-   return obj->vaddr;
+   if (obj->vaddr)
+   return obj->vaddr;
+   else if (obj->gem.import_attach)
+   return dma_buf_vmap(obj->gem.import_attach->dmabuf);
+   else
+   return vmap(obj->pages, obj->num_pages, VM_MAP,
+   pgprot_writecombine(PAGE_KERNEL));
 }

 static void tegra_bo_munmap(struct host1x_bo *bo, void *addr)
 {
+   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
+
+   if (obj->vaddr)
+   return;
+   else if (obj->gem.import_attach)
+   dma_buf_vunmap(obj->gem.import_attach->dmabuf, addr);
+   else
+   vunmap(addr);
 }

 static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int page)
 {
struct tegra_bo *obj = host1x_to_tegra_bo(bo);

-   return obj->vaddr + page * PAGE_SIZE;
+   if (obj->vaddr)
+   return obj->vaddr + page * PAGE_SIZE;
+   else if (obj->gem.import_attach)
+   return dma_buf_kmap(obj->gem.import_attach->dmabuf, page);
+   else
+   return vmap(obj->pages + page, 1, VM_MAP,
+   pgprot_writecombine(PAGE_KERNEL));
 }

 static void tegra_bo_kunmap(struct host1x_bo *bo, unsigned int page,
void *addr)
 {
+   struct tegra_bo *obj = host1x_to_tegra_bo(bo);
+
+   if (obj->vaddr)
+   return;
+   else if (obj->gem.import_attach)
+   dma_buf_kunmap(obj->gem.import_attach->dmabuf, page, addr);
+   else
+   vunmap(addr);
 }

 static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
-- 
2.1.4

[PATCH 3/5] host1x: Handle HOST1X class address registers directly

[Mikko Perttunen]

This moves handling of address registers in the HOST1X class directly
to the firewall code in host1x's job.c, so that individual clients don't
have to replicate this code. The list of address registers detected also
change from INDCTRL which is not actually an address register to INDOFF
and INDOFF2 which are.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/gr2d.c | 21 ++---
 drivers/gpu/drm/tegra/gr3d.c | 20 ++--
 drivers/gpu/host1x/job.c | 12 +++-
 3 files changed, 23 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 7e4424f..f048d45 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -88,23 +88,14 @@ static int gr2d_is_addr_reg(struct device *dev, u32 class, 
u32 offset, u32 val)
 {
struct gr2d *gr2d = dev_get_drvdata(dev);

-   switch (class) {
-   case HOST1X_CLASS_HOST1X:
-   if (offset == 0x2b)
-   return 1;
+   if (class != HOST1X_CLASS_GR2D && class != HOST1X_CLASS_GR2D_SB)
+   return 0;

-   break;
+   if (offset >= GR2D_NUM_REGS)
+   return 0;

-   case HOST1X_CLASS_GR2D:
-   case HOST1X_CLASS_GR2D_SB:
-   if (offset >= GR2D_NUM_REGS)
-   break;
-
-   if (test_bit(offset, gr2d->addr_regs))
-   return 1;
-
-   break;
-   }
+   if (test_bit(offset, gr2d->addr_regs))
+   return 1;

return 0;
 }
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 9ceaf35..d0dab15 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -98,22 +98,14 @@ static int gr3d_is_addr_reg(struct device *dev, u32 class, 
u32 offset, u32 val)
 {
struct gr3d *gr3d = dev_get_drvdata(dev);

-   switch (class) {
-   case HOST1X_CLASS_HOST1X:
-   if (offset == 0x2b)
-   return 1;
+   if (class != HOST1X_CLASS_GR3D)
+   return 0;

-   break;
+   if (offset >= GR3D_NUM_REGS)
+   return 0;

-   case HOST1X_CLASS_GR3D:
-   if (offset >= GR3D_NUM_REGS)
-   break;
-
-   if (test_bit(offset, gr3d->addr_regs))
-   return 1;
-
-   break;
-   }
+   if (test_bit(offset, gr3d->addr_regs))
+   return 1;

return 0;
 }
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 77d977b..0701008 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -295,10 +295,20 @@ struct host1x_firewall {
u32 count;
 };

+static int is_addr_reg(struct host1x_firewall *fw, unsigned long offset,
+  u32 val)
+{
+   if (fw->class == HOST1X_CLASS_HOST1X &&
+   (offset == 0x2c /* INDOFF2 */ || offset == 0x2d /* INDOFF */))
+   return true;
+
+   return fw->job->is_addr_reg(fw->dev, fw->class, offset, val);
+}
+
 static int check_register(struct host1x_firewall *fw,
  unsigned long offset, u32 val)
 {
-   if (fw->job->is_addr_reg(fw->dev, fw->class, offset, val)) {
+   if (is_addr_reg(fw, offset, val)) {
if (!fw->num_relocs)
return -EINVAL;

-- 
2.1.4

[PATCH 2/5] host1x: Pass register value in firewall

[Mikko Perttunen]

From: Arto Merilainen 

In gr2d and gr3d units the register offset was sufficient for determining
if the register in interest is used for storing a register value.

However, in VIC this is not the case. The operations are passed through
two registers, METHOD0 and METHOD1. Depending on content of METHOD0,
METHOD1 can be either address or data field.

This patch updates the firewall interface to deliver also the register
value to allow book-keeping inside the engine driver.

Signed-off-by: Arto Merilainen 
Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/drm.h  |  4 ++--
 drivers/gpu/drm/tegra/gr2d.c |  4 ++--
 drivers/gpu/drm/tegra/gr3d.c |  4 ++--
 drivers/gpu/host1x/job.c | 35 +++
 include/linux/host1x.h   |  4 ++--
 5 files changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 659b2fc..0e7756e 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2012 Avionic Design GmbH
- * Copyright (C) 2012-2013 NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (C) 2012-2015 NVIDIA CORPORATION.  All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -70,7 +70,7 @@ struct tegra_drm_client_ops {
int (*open_channel)(struct tegra_drm_client *client,
struct tegra_drm_context *context);
void (*close_channel)(struct tegra_drm_context *context);
-   int (*is_addr_reg)(struct device *dev, u32 class, u32 offset);
+   int (*is_addr_reg)(struct device *dev, u32 class, u32 offset, u32 val);
int (*submit)(struct tegra_drm_context *context,
  struct drm_tegra_submit *args, struct drm_device *drm,
  struct drm_file *file);
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 02cd3e3..7e4424f 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2012-2013, NVIDIA Corporation.
+ * Copyright (c) 2012-2015, NVIDIA Corporation.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -84,7 +84,7 @@ static void gr2d_close_channel(struct tegra_drm_context 
*context)
host1x_channel_put(context->channel);
 }

-static int gr2d_is_addr_reg(struct device *dev, u32 class, u32 offset)
+static int gr2d_is_addr_reg(struct device *dev, u32 class, u32 offset, u32 val)
 {
struct gr2d *gr2d = dev_get_drvdata(dev);

diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 0b3f2b9..9ceaf35 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -1,6 +1,6 @@
 /*
  * Copyright (C) 2013 Avionic Design GmbH
- * Copyright (C) 2013 NVIDIA Corporation
+ * Copyright (C) 2013-2015 NVIDIA Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -94,7 +94,7 @@ static void gr3d_close_channel(struct tegra_drm_context 
*context)
host1x_channel_put(context->channel);
 }

-static int gr3d_is_addr_reg(struct device *dev, u32 class, u32 offset)
+static int gr3d_is_addr_reg(struct device *dev, u32 class, u32 offset, u32 val)
 {
struct gr3d *gr3d = dev_get_drvdata(dev);

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index b72aa91..77d977b 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -295,9 +295,10 @@ struct host1x_firewall {
u32 count;
 };

-static int check_register(struct host1x_firewall *fw, unsigned long offset)
+static int check_register(struct host1x_firewall *fw,
+ unsigned long offset, u32 val)
 {
-   if (fw->job->is_addr_reg(fw->dev, fw->class, offset)) {
+   if (fw->job->is_addr_reg(fw->dev, fw->class, offset, val)) {
if (!fw->num_relocs)
return -EINVAL;

@@ -311,18 +312,21 @@ static int check_register(struct host1x_firewall *fw, 
unsigned long offset)
return 0;
 }

-static int check_mask(struct host1x_firewall *fw)
+static int check_mask(struct host1x_firewall *fw, struct host1x_job_gather *g)
 {
+   u32 *cmdbuf_base = (u32 *)fw->job->gather_copy_mapped +
+   (g->offset / sizeof(u32));
u32 mask = fw->mask;
u32 reg = fw->reg;
int ret;

while (mask) {
+   u32 val = cmdbuf_base[fw->offset];
if (fw->words == 0)
return -EINVAL;

if (mask & 1) {
-   ret = check_register(fw, reg);
+   ret = check_register(fw, reg, val);
if (ret < 0)
return ret;

@@ -336,17 

[PATCH 1/5] host1x: Store device address to all bufs

[Mikko Perttunen]

From: Arto Merilainen 

Currently job pinning is optimized to handle only the first buffer
using a certain host1x_bo object and all subsequent buffers using
the same host1x_bo are considered done.

In most cases this is correct, however, in case the same host1x_bo
is used in multiple gathers inside the same job, we skip also
storing the device address (physical or iova) to this buffer.

This patch reworks the host1x_job_pin() to store the device address
to all gathers.

Signed-off-by: Andrew Chew 
Signed-off-by: Arto Merilainen 
Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/host1x/job.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 63bd63f..b72aa91 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -1,7 +1,7 @@
 /*
  * Tegra host1x Job
  *
- * Copyright (c) 2010-2013, NVIDIA Corporation.
+ * Copyright (c) 2010-2015, NVIDIA Corporation.
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -538,9 +538,12 @@ int host1x_job_pin(struct host1x_job *job, struct device 
*dev)

g->base = job->gather_addr_phys[i];

-   for (j = i + 1; j < job->num_gathers; j++)
-   if (job->gathers[j].bo == g->bo)
+   for (j = i + 1; j < job->num_gathers; j++) {
+   if (job->gathers[j].bo == g->bo) {
job->gathers[j].handled = true;
+   job->gathers[j].base = g->base;
+   }
+   }

err = do_relocs(job, g->bo);
if (err)
-- 
2.1.4

[PATCH 0/5] Host1x/TegraDRM fixes/improvements

[Mikko Perttunen]

Hi, this series has a few small improvements for Host1x and TegraDRM
that the VIC series will build upon.

1/5 is a bug fix to host1x.
2/5 is required by VIC code to implement ->is_addr_reg().
3/5 deduplicates handling of HOST1X class address registers
and fixes the checked registers.
4/5 is required for the host1x firewall to work when bo's are
mapped using IOMMU.
5/5 adds a TegraDRM allocator that allows drivers to allocate
non-GEM memory that is still mapped to the TegraDRM domain.

Arto Merilainen (3):
  host1x: Store device address to all bufs
  host1x: Pass register value in firewall
  drm/tegra: Support kernel mappings with IOMMU

Mikko Perttunen (2):
  host1x: Handle HOST1X class address registers directly
  drm/tegra: Add Tegra DRM allocation API

 drivers/gpu/drm/tegra/drm.c  | 99 +---
 drivers/gpu/drm/tegra/drm.h  | 13 +-
 drivers/gpu/drm/tegra/gem.c  | 34 +--
 drivers/gpu/drm/tegra/gr2d.c | 25 ---
 drivers/gpu/drm/tegra/gr3d.c | 24 ---
 drivers/gpu/host1x/job.c | 54 +---
 include/linux/host1x.h   |  4 +-
 7 files changed, 193 insertions(+), 60 deletions(-)

-- 
2.1.4

[PATCH 2/2] drm/ttm: improve uncached page deallocation.

[j.gli...@gmail.com]

From: Jérôme Glisse 

Calls to set_memory_wb() incure heavy TLB flush and IPI cost. To
minimize those wait until pool grow beyond batch size before
draining the pool.

Signed-off-by: Jérôme Glisse 
Reviewed-by: Mario Kleiner 
Cc: Michel Dänzer 
Cc: Thomas Hellstrom 
Cc: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 0194a93..8028dd6 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -953,7 +953,12 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
} else {
pool->npages_free += count;
list_splice(_dma->pages_list, >free_list);
-   if (pool->npages_free > _manager->options.max_size)
+   /*
+* Wait to have at at least NUM_PAGES_TO_ALLOC number of pages
+* to free in order to minimize calls to set_memory_wb().
+*/
+   if (pool->npages_free >= (_manager->options.max_size +
+ NUM_PAGES_TO_ALLOC))
npages = pool->npages_free - _manager->options.max_size;
}
spin_unlock_irqrestore(>lock, irq_flags);
-- 
1.8.3.1

[PATCH 1/2] drm/ttm: fix object deallocation to properly fill in the page pool.

[j.gli...@gmail.com]

From: Jérôme Glisse 

Current code never allowed the page pool to actualy fill in anyway.
This fix it, so that we only start freeing page from the pool when
we go over the pool size.

Signed-off-by: Jérôme Glisse 
Reviewed-by: Mario Kleiner 
Tested-by: Michel Dänzer 
Cc: Thomas Hellstrom 
Cc: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index c96db43..0194a93 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -953,14 +953,8 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct 
device *dev)
} else {
pool->npages_free += count;
list_splice(_dma->pages_list, >free_list);
-   npages = count;
-   if (pool->npages_free > _manager->options.max_size) {
+   if (pool->npages_free > _manager->options.max_size)
npages = pool->npages_free - _manager->options.max_size;
-   /* free at least NUM_PAGES_TO_ALLOC number of pages
-* to reduce calls to set_memory_wb */
-   if (npages < NUM_PAGES_TO_ALLOC)
-   npages = NUM_PAGES_TO_ALLOC;
-   }
}
spin_unlock_irqrestore(>lock, irq_flags);

-- 
1.8.3.1

[PATCH] drm: Add Grain Media GM12U320 kms driver

[Hans de Goede]

Grain-media GM12U320 based devices are mini video projectors using USB for
both power and video data transport.

This commit adds a kms driver for these devices, including prime support.

This driver is based on the existing udl kms driver, and the gm12u320
fb driver by Viacheslav Nurmekhamitov .

Signed-off-by: Hans de Goede 
---
 MAINTAINERS   |   6 +
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/gm12u320/Kconfig  |  16 +
 drivers/gpu/drm/gm12u320/Makefile |   7 +
 drivers/gpu/drm/gm12u320/gm12u320_connector.c | 151 
 drivers/gpu/drm/gm12u320/gm12u320_dmabuf.c| 283 +++
 drivers/gpu/drm/gm12u320/gm12u320_drv.c   | 160 +
 drivers/gpu/drm/gm12u320/gm12u320_drv.h   | 131 +++
 drivers/gpu/drm/gm12u320/gm12u320_encoder.c   |  83 +
 drivers/gpu/drm/gm12u320/gm12u320_fb.c| 420 ++
 drivers/gpu/drm/gm12u320/gm12u320_gem.c   | 241 +
 drivers/gpu/drm/gm12u320/gm12u320_main.c  | 499 ++
 drivers/gpu/drm/gm12u320/gm12u320_modeset.c   | 152 
 14 files changed, 2152 insertions(+)
 create mode 100644 drivers/gpu/drm/gm12u320/Kconfig
 create mode 100644 drivers/gpu/drm/gm12u320/Makefile
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_connector.c
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_dmabuf.c
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_drv.c
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_drv.h
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_encoder.c
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_fb.c
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_gem.c
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_main.c
 create mode 100644 drivers/gpu/drm/gm12u320/gm12u320_modeset.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..4caab0c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3543,6 +3543,12 @@ S:   Maintained
 F: drivers/gpu/drm/imx/
 F: Documentation/devicetree/bindings/drm/imx/

+DRM DRIVERS FOR GRAIN-MEDIA GM12U320
+M: Hans de Goede 
+L: dri-devel at lists.freedesktop.org
+S: Supported
+F: drivers/gpu/drm/gm12u320/
+
 DRM DRIVERS FOR NVIDIA TEGRA
 M: Thierry Reding 
 M: Terje Bergström 
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c46ca31..1da77e1 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -240,3 +240,5 @@ source "drivers/gpu/drm/sti/Kconfig"
 source "drivers/gpu/drm/amd/amdkfd/Kconfig"

 source "drivers/gpu/drm/imx/Kconfig"
+
+source "drivers/gpu/drm/gm12u320/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 5713d05..4499395 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_DRM_MSM) += msm/
 obj-$(CONFIG_DRM_TEGRA) += tegra/
 obj-$(CONFIG_DRM_STI) += sti/
 obj-$(CONFIG_DRM_IMX) += imx/
+obj-$(CONFIG_DRM_GM12U320) += gm12u320/
 obj-y  += i2c/
 obj-y  += panel/
 obj-y  += bridge/
diff --git a/drivers/gpu/drm/gm12u320/Kconfig b/drivers/gpu/drm/gm12u320/Kconfig
new file mode 100644
index 000..cfecaac
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/Kconfig
@@ -0,0 +1,16 @@
+config DRM_GM12U320
+   tristate "Grain Media GM12U320 based mini projectors"
+   depends on DRM
+   depends on USB_SUPPORT
+   depends on USB_ARCH_HAS_HCD
+   select USB
+   select FB_SYS_FILLRECT
+   select FB_SYS_COPYAREA
+   select FB_SYS_IMAGEBLIT
+   select FB_DEFERRED_IO
+   select DRM_KMS_HELPER
+select DRM_KMS_FB_HELPER
+   help
+ This is a KMS driver for Grain Media GM12U320 based usb mini video
+ projectors, such as the Acer C120.
+ Say M/Y to add support for these devices via drm/kms interfaces.
diff --git a/drivers/gpu/drm/gm12u320/Makefile 
b/drivers/gpu/drm/gm12u320/Makefile
new file mode 100644
index 000..6234473
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/Makefile
@@ -0,0 +1,7 @@
+ccflags-y := -Iinclude/drm
+
+gm12u320-y :=  gm12u320_drv.o gm12u320_modeset.o gm12u320_connector.o \
+   gm12u320_encoder.o gm12u320_main.o gm12u320_fb.o \
+   gm12u320_gem.o gm12u320_dmabuf.o
+
+obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
diff --git a/drivers/gpu/drm/gm12u320/gm12u320_connector.c 
b/drivers/gpu/drm/gm12u320/gm12u320_connector.c
new file mode 100644
index 000..96880d7
--- /dev/null
+++ b/drivers/gpu/drm/gm12u320/gm12u320_connector.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (C) 2012-2015 Red Hat Inc.
+ *
+ * Based in parts on the udl code. Based in parts on the gm12u320 fb driver:
+ * Copyright (C) 2013 Viacheslav Nurmekhamitov 
+ * Copyright (C) 2009 Roberto De Ioris 
+ * Copyright (C) 2009 Jaya Kumar 
+ * Copyright (C) 2009 Bernie Thompson 
+ *
+ * This file is subject to the terms and conditions of the 

[PATCH 0/1] drm: Add Grain Media GM12U320 kms driver

[Hans de Goede]

Hi All,

Here is a kms driver, including prime support for Grain-media GM12U320
based USB mini video projectors. These projectors use USB for both power
and video data transport.

This driver is based on the udl code, where as the GM12U320 usb protocol
specific bits come from Viacheslav Nurmekhamitov 's
gm12u320 fb driver.

The gm12u320_gem.c and _dmabuf.c files are 100% identical to the udl ones
except for a s/udl/gm12u320/, as such we should consider creating a shared
implemantation of these, IMHO this is best done in a followup patch.

This patch is against 4.2-rc1, but it has only been tested build standalone
against 4.1 as 4.2-rc1 does not boor for me.

Regards,

Hans

R200 DRM/KMS

[Steven Newbury]

On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
> On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury  
> wrote:
> >
> >
> > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> >> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  
> >> wrote:
> >> >
> >> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> >> > gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
> >> > could be interfering but triggering a device "remove" before starting
> >> > X made no difference.
> >> >
> >> > I'm a bit of a loss.  I suppose I could try writing a simple test for
> >> > drmSetInterfaceVersion().  At least that should determine whether the
> >> > xserver/ddx is in the clear.
> >> >
> >> > Any other ideas?
> >> >
> >>
> >> Can you start a non-X runlevel and start X manually as root (assuming
> >> you are using a login manager now)?
> >>
> > My test program worked fine. I considerably improved it over the version I 
> > posted. I'll send it to the list when I get back.
> >
> > I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much 
> > further.  Starting Xserver as root  apparently started normally, according 
> > to the log, although  there was a permission denied error on mode set 
> > during init. I don't know whether it was related or not, but the display 
> > then hung with a non-blinking cursor. Strange to get a permission denied as 
> > root!
> >
> > Starting GNOME via gdm gives a working slow X session but for some reason 
> > only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. 
> > Perhaps it's a config error somewhere.. ?
> >
> > startx as a regular user just works!
> >
> > But mutter doesn't, perhaps that's
> > why a gnome session isn't working. It just gives the following error:
> > Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
> >
> > Mutter is supposed to work on r200, right?
> 
> IIRC it tries to use a render buffer format that's not supported by the hw.
Is there anything to be done about it? Have to use a different wm/compositor? 

Any idea why removing the call from radeon_kms.c worked?

-- 
Sent from my Jolla

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

[John Hunter]

On Mon, Jul 6, 2015 at 4:01 PM, SF Markus Elfring <
elfring at users.sourceforge.net> wrote:

> From: Markus Elfring 
> Date: Mon, 6 Jul 2015 09:49:11 +0200
>
> The vfree() function performs 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 
>

Reviewed-by: Zhao Junwang 

kfree will check that.

> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> index 654c8da..f718a6d 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
> @@ -2292,9 +2292,7 @@ static int vmw_resize_cmd_bounce(struct
> vmw_sw_context *sw_context,
>(sw_context->cmd_bounce_size >> 1));
> }
>
> -   if (sw_context->cmd_bounce != NULL)
> -   vfree(sw_context->cmd_bounce);
> -
> +   vfree(sw_context->cmd_bounce);
> sw_context->cmd_bounce = vmalloc(sw_context->cmd_bounce_size);
>
> if (sw_context->cmd_bounce == NULL) {
> --
> 2.4.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>



-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/310af3ed/attachment.html>

[PATCH 3/3] drm/radeon/cayman/tn: only enable CP gui idle interrupts after CP is set up

[Alex Deucher]

Necessary for proper gfx/rlc/smu handshaking.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/evergreen.c | 35 ++-
 drivers/gpu/drm/radeon/ni.c| 29 ++---
 drivers/gpu/drm/radeon/nid.h   |  3 +++
 3 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 0e0fb07..b7f3a18 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -205,8 +205,8 @@ static void evergreen_gpu_init(struct radeon_device *rdev);
 void evergreen_fini(struct radeon_device *rdev);
 void evergreen_pcie_gen2_enable(struct radeon_device *rdev);
 void evergreen_program_aspm(struct radeon_device *rdev);
-extern void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
-int ring, u32 cp_int_cntl);
+extern void cayman_cp_int_cntl_select(struct radeon_device *rdev,
+ int ring);
 extern void cayman_vm_decode_fault(struct radeon_device *rdev,
   u32 status, u32 addr);
 void cik_init_cp_pg_table(struct radeon_device *rdev);
@@ -4419,10 +4419,14 @@ void evergreen_disable_interrupt_state(struct 
radeon_device *rdev)
u32 tmp;

if (rdev->family >= CHIP_CAYMAN) {
-   cayman_cp_int_cntl_setup(rdev, 0,
-CNTX_BUSY_INT_ENABLE | 
CNTX_EMPTY_INT_ENABLE);
-   cayman_cp_int_cntl_setup(rdev, 1, 0);
-   cayman_cp_int_cntl_setup(rdev, 2, 0);
+   mutex_lock(>grbm_idx_mutex);
+   cayman_cp_int_cntl_select(rdev, 0);
+   WREG32(CP_INT_CNTL, 0);
+   cayman_cp_int_cntl_select(rdev, 1);
+   WREG32(CP_INT_CNTL, 0);
+   cayman_cp_int_cntl_select(rdev, 2);
+   WREG32(CP_INT_CNTL, 0);
+   mutex_unlock(>grbm_idx_mutex);
tmp = RREG32(CAYMAN_DMA1_CNTL) & ~TRAP_ENABLE;
WREG32(CAYMAN_DMA1_CNTL, tmp);
} else
@@ -4519,19 +4523,27 @@ int evergreen_irq_set(struct radeon_device *rdev)
dma_cntl = RREG32(DMA_CNTL) & ~TRAP_ENABLE;

if (rdev->family >= CHIP_CAYMAN) {
+   mutex_lock(>grbm_idx_mutex);
/* enable CP interrupts on all rings */
+   cayman_cp_int_cntl_select(rdev, 0);
+   cp_int_cntl = RREG32(CP_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
if 
(atomic_read(>irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
DRM_DEBUG("evergreen_irq_set: sw int gfx\n");
cp_int_cntl |= TIME_STAMP_INT_ENABLE;
}
+   cayman_cp_int_cntl_select(rdev, 1);
+   cp_int_cntl1 = RREG32(CP_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
if 
(atomic_read(>irq.ring_int[CAYMAN_RING_TYPE_CP1_INDEX])) {
DRM_DEBUG("evergreen_irq_set: sw int cp1\n");
cp_int_cntl1 |= TIME_STAMP_INT_ENABLE;
}
+   cayman_cp_int_cntl_select(rdev, 2);
+   cp_int_cntl2 = RREG32(CP_INT_CNTL) & ~TIME_STAMP_INT_ENABLE;
if 
(atomic_read(>irq.ring_int[CAYMAN_RING_TYPE_CP2_INDEX])) {
DRM_DEBUG("evergreen_irq_set: sw int cp2\n");
cp_int_cntl2 |= TIME_STAMP_INT_ENABLE;
}
+   mutex_unlock(>grbm_idx_mutex);
} else {
cp_int_cntl = RREG32(CP_INT_CNTL) & ~(RB_INT_ENABLE | 
TIME_STAMP_INT_ENABLE);
if 
(atomic_read(>irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
@@ -4639,9 +4651,14 @@ int evergreen_irq_set(struct radeon_device *rdev)
}

if (rdev->family >= CHIP_CAYMAN) {
-   cayman_cp_int_cntl_setup(rdev, 0, cp_int_cntl);
-   cayman_cp_int_cntl_setup(rdev, 1, cp_int_cntl1);
-   cayman_cp_int_cntl_setup(rdev, 2, cp_int_cntl2);
+   mutex_lock(>grbm_idx_mutex);
+   cayman_cp_int_cntl_select(rdev, 0);
+   WREG32(CP_INT_CNTL, cp_int_cntl);
+   cayman_cp_int_cntl_select(rdev, 1);
+   WREG32(CP_INT_CNTL, cp_int_cntl1);
+   cayman_cp_int_cntl_select(rdev, 2);
+   WREG32(CP_INT_CNTL, cp_int_cntl2);
+   mutex_unlock(>grbm_idx_mutex);
} else
WREG32(CP_INT_CNTL, cp_int_cntl);

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 6de9d363..2b2e177 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1393,13 +1393,12 @@ static void cayman_pcie_gart_fini(struct radeon_device 
*rdev)
radeon_gart_fini(rdev);
 }

-void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
- int ring, u32 cp_int_cntl)
+void cayman_cp_int_cntl_select(struct radeon_device *rdev,
+  int ring)
 {
u32 

[PATCH 2/3] drm/radeon/evergreen: only enable CP gui idle interrupts after CP is set up

[Alex Deucher]

Necessary for proper gfx/rlc/smu handshaking.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c | 12 ++--
 drivers/gpu/drm/radeon/r600.c  |  4 ++--
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 0acde19..0e0fb07 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -216,6 +216,8 @@ extern void si_get_csb_buffer(struct radeon_device *rdev, 
volatile u32 *buffer);
 extern u32 cik_get_csb_size(struct radeon_device *rdev);
 extern void cik_get_csb_buffer(struct radeon_device *rdev, volatile u32 
*buffer);
 extern void rv770_set_clk_bypass_mode(struct radeon_device *rdev);
+extern void r600_enable_gui_idle_interrupt(struct radeon_device *rdev,
+  bool enable);

 static const u32 evergreen_golden_registers[] =
 {
@@ -3037,6 +3039,8 @@ static int evergreen_cp_resume(struct radeon_device *rdev)
WREG32(GRBM_SOFT_RESET, 0);
RREG32(GRBM_SOFT_RESET);

+   r600_enable_gui_idle_interrupt(rdev, false);
+
/* Set ring buffer size */
rb_bufsz = order_base_2(ring->ring_size / 8);
tmp = (order_base_2(RADEON_GPU_PAGE_SIZE/8) << 8) | rb_bufsz;
@@ -3082,6 +3086,9 @@ static int evergreen_cp_resume(struct radeon_device *rdev)
ring->ready = false;
return r;
}
+
+   r600_enable_gui_idle_interrupt(rdev, true);
+
return 0;
 }

@@ -4419,7 +4426,7 @@ void evergreen_disable_interrupt_state(struct 
radeon_device *rdev)
tmp = RREG32(CAYMAN_DMA1_CNTL) & ~TRAP_ENABLE;
WREG32(CAYMAN_DMA1_CNTL, tmp);
} else
-   WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | 
CNTX_EMPTY_INT_ENABLE);
+   WREG32(CP_INT_CNTL, 0);
tmp = RREG32(DMA_CNTL) & ~TRAP_ENABLE;
WREG32(DMA_CNTL, tmp);
WREG32(GRBM_INT_CNTL, 0);
@@ -4468,7 +4475,7 @@ void evergreen_disable_interrupt_state(struct 
radeon_device *rdev)

 int evergreen_irq_set(struct radeon_device *rdev)
 {
-   u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
+   u32 cp_int_cntl = 0;
u32 cp_int_cntl1 = 0, cp_int_cntl2 = 0;
u32 crtc1 = 0, crtc2 = 0, crtc3 = 0, crtc4 = 0, crtc5 = 0, crtc6 = 0;
u32 hpd1, hpd2, hpd3, hpd4, hpd5, hpd6;
@@ -4526,6 +4533,7 @@ int evergreen_irq_set(struct radeon_device *rdev)
cp_int_cntl2 |= TIME_STAMP_INT_ENABLE;
}
} else {
+   cp_int_cntl = RREG32(CP_INT_CNTL) & ~(RB_INT_ENABLE | 
TIME_STAMP_INT_ENABLE);
if 
(atomic_read(>irq.ring_int[RADEON_RING_TYPE_GFX_INDEX])) {
DRM_DEBUG("evergreen_irq_set: sw int gfx\n");
cp_int_cntl |= RB_INT_ENABLE;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 0bc39cd..df59d8c 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2710,8 +2710,8 @@ int r600_cp_start(struct radeon_device *rdev)
return 0;
 }

-static void r600_enable_gui_idle_interrupt(struct radeon_device *rdev,
-  bool enable)
+void r600_enable_gui_idle_interrupt(struct radeon_device *rdev,
+   bool enable)
 {
u32 tmp = RREG32(CP_INT_CNTL);

-- 
1.8.3.1

[PATCH 1/3] drm/radeon/r600/r700: only enable CP gui idle interrupts after CP is set up

[Alex Deucher]

Necessary for proper gfx/rlc/smu handshaking.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/r600.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4ea5b10..0bc39cd 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2710,6 +2710,22 @@ int r600_cp_start(struct radeon_device *rdev)
return 0;
 }

+static void r600_enable_gui_idle_interrupt(struct radeon_device *rdev,
+  bool enable)
+{
+   u32 tmp = RREG32(CP_INT_CNTL);
+
+   if (enable)
+   tmp |= (CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
+   else
+   tmp &= ~(CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
+   WREG32(CP_INT_CNTL, tmp);
+
+   if (!enable)
+   /* read a gfx register */
+   tmp = RREG32(R_028010_DB_DEPTH_INFO);
+}
+
 int r600_cp_resume(struct radeon_device *rdev)
 {
struct radeon_ring *ring = >ring[RADEON_RING_TYPE_GFX_INDEX];
@@ -2723,6 +2739,8 @@ int r600_cp_resume(struct radeon_device *rdev)
mdelay(15);
WREG32(GRBM_SOFT_RESET, 0);

+   r600_enable_gui_idle_interrupt(rdev, false);
+
/* Set ring buffer size */
rb_bufsz = order_base_2(ring->ring_size / 8);
tmp = (order_base_2(RADEON_GPU_PAGE_SIZE/8) << 8) | rb_bufsz;
@@ -2768,6 +2786,8 @@ int r600_cp_resume(struct radeon_device *rdev)
return r;
}

+   r600_enable_gui_idle_interrupt(rdev, true);
+
if (rdev->asic->copy.copy_ring_index == RADEON_RING_TYPE_GFX_INDEX)
radeon_ttm_set_active_vram_size(rdev, rdev->mc.real_vram_size);

@@ -3573,7 +3593,7 @@ static void r600_disable_interrupt_state(struct 
radeon_device *rdev)
 {
u32 tmp;

-   WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE);
+   WREG32(CP_INT_CNTL, 0);
tmp = RREG32(DMA_CNTL) & ~TRAP_ENABLE;
WREG32(DMA_CNTL, tmp);
WREG32(GRBM_INT_CNTL, 0);
@@ -3714,7 +3734,7 @@ void r600_irq_fini(struct radeon_device *rdev)

 int r600_irq_set(struct radeon_device *rdev)
 {
-   u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
+   u32 cp_int_cntl;
u32 mode_int = 0;
u32 hpd1, hpd2, hpd3, hpd4 = 0, hpd5 = 0, hpd6 = 0;
u32 grbm_int_cntl = 0;
@@ -3734,6 +3754,8 @@ int r600_irq_set(struct radeon_device *rdev)
return 0;
}

+   cp_int_cntl = RREG32(CP_INT_CNTL) & ~(RB_INT_ENABLE | 
TIME_STAMP_INT_ENABLE);
+
if (ASIC_IS_DCE3(rdev)) {
hpd1 = RREG32(DC_HPD1_INT_CONTROL) & ~DC_HPDx_INT_EN;
hpd2 = RREG32(DC_HPD2_INT_CONTROL) & ~DC_HPDx_INT_EN;
-- 
1.8.3.1

[PATCH] drm/radeon: disable vce init on cayman

[Alex Deucher]

Cayman does not have vce.  There were a few places in the
shared cayman/TV code where we were trying to do vce stuff.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ni.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 6a8afe2..2b2e177 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2185,18 +2185,20 @@ static int cayman_startup(struct radeon_device *rdev)
DRM_ERROR("radeon: failed initializing UVD (%d).\n", r);
}

-   ring = >ring[TN_RING_TYPE_VCE1_INDEX];
-   if (ring->ring_size)
-   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
+   if (rdev->family == CHIP_ARUBA) {
+   ring = >ring[TN_RING_TYPE_VCE1_INDEX];
+   if (ring->ring_size)
+   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 
0x0);

-   ring = >ring[TN_RING_TYPE_VCE2_INDEX];
-   if (ring->ring_size)
-   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
+   ring = >ring[TN_RING_TYPE_VCE2_INDEX];
+   if (ring->ring_size)
+   r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 
0x0);

-   if (!r)
-   r = vce_v1_0_init(rdev);
-   else if (r != -ENOENT)
-   DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
+   if (!r)
+   r = vce_v1_0_init(rdev);
+   else if (r != -ENOENT)
+   DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
+   }

r = radeon_ib_pool_init(rdev);
if (r) {
@@ -2419,7 +2421,8 @@ void cayman_fini(struct radeon_device *rdev)
radeon_irq_kms_fini(rdev);
uvd_v1_0_fini(rdev);
radeon_uvd_fini(rdev);
-   radeon_vce_fini(rdev);
+   if (rdev->family == CHIP_ARUBA)
+   radeon_vce_fini(rdev);
cayman_pcie_gart_fini(rdev);
r600_vram_scratch_fini(rdev);
radeon_gem_fini(rdev);
-- 
1.8.3.1

R200 DRM/KMS

[Steven Newbury]

On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  
> wrote:
> >
> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
> > gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
> > could be interfering but triggering a device "remove" before starting
> > X made no difference.
> >
> > I'm a bit of a loss.  I suppose I could try writing a simple test for
> > drmSetInterfaceVersion().  At least that should determine whether the
> > xserver/ddx is in the clear.
> >
> > Any other ideas?
> >
> 
> Can you start a non-X runlevel and start X manually as root (assuming
> you are using a login manager now)?
> 
My test program worked fine. I considerably improved it over the version I 
posted. I'll send it to the list when I get back.

I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much 
further.  Starting Xserver as root  apparently started normally, according to 
the log, although  there was a permission denied error on mode set during init. 
I don't know whether it was related or not, but the display then hung with a 
non-blinking cursor. Strange to get a permission denied as root!

Starting GNOME via gdm gives a working slow X session but for some reason only 
uses sw dri even though the Xorg log shows r200 DRI2 as initialized. Perhaps 
it's a config error somewhere.. ?

startx as a regular user just works! 

But mutter doesn't, perhaps that's 
why a gnome session isn't working. It just gives the following error:
Cogl-ERROR **: Failed to create texture 2d due to size/format constraints

Mutter is supposed to work on r200, right?


-- 
Sent from my Jolla

[PATCH 1/2] drm/radeon: allways add the VM clear duplicate

[Alex Deucher]

On Wed, Jul 8, 2015 at 12:31 PM, Christian König
 wrote:
> On 08.07.2015 18:14, Alex Deucher wrote:
>>
>> On Wed, Jul 8, 2015 at 12:08 PM, Christian König
>>  wrote:
>>>
>>> On 08.07.2015 17:57, Alex Deucher wrote:

 On Wed, Jul 8, 2015 at 3:56 AM, Christian König
 
 wrote:
>
> From: Christian König 
>
> We need to allways add the VM clear duplicate of the BO_VA,
> no matter what the old status was.
>
> Signed-off-by: Christian König 
> Test-by: hadack at gmx.de

 This patch does not apply cleanly.  It also adds an undefined label
 error_unreserve.  Is there an additional patch required?
>>>
>>>
>>> That's possible, but I thought the depending patch would have already
>>> been
>>> upstream.
>>>
>>> Can you create a drm-fixes-4.2 branch I can rebase on?
>>
>> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.2-wip
>
>
> Ah, here is the problem. This branch don't yet contains the fixes which went
> upstream with 4.1.
>
> What should we do? I don't want to change those patches and create a merge
> conflict when you merge in 4.1.

I'll rebase by tree on Linus' tree.  Dave is on vacation so his tree is lagging.

Alex

>
> Christian.
>
>
>>
>> Thanks,
>>
>> Alex
>>
>>> Thanks,
>>> Christian.
>>>
>>>
 Alex

> ---
>drivers/gpu/drm/radeon/radeon_vm.c | 34
> --
>1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index ec10533..0310965 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -493,29 +493,27 @@ int radeon_vm_bo_set_addr(struct radeon_device
> *rdev,
>   }
>
>   if (bo_va->it.start || bo_va->it.last) {
> -   spin_lock(>status_lock);
> -   if (list_empty(_va->vm_status)) {
> -   /* add a clone of the bo_va to clear the old
> address */
> -   struct radeon_bo_va *tmp;
> -   spin_unlock(>status_lock);
> -   tmp = kzalloc(sizeof(struct radeon_bo_va),
> GFP_KERNEL);
> -   if (!tmp) {
> -   mutex_unlock(>mutex);
> -   r = -ENOMEM;
> -   goto error_unreserve;
> -   }
> -   tmp->it.start = bo_va->it.start;
> -   tmp->it.last = bo_va->it.last;
> -   tmp->vm = vm;
> -   tmp->bo = radeon_bo_ref(bo_va->bo);
> -   spin_lock(>status_lock);
> -   list_add(>vm_status, >freed);
> +   /* add a clone of the bo_va to clear the old address */
> +   struct radeon_bo_va *tmp;
> +   tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
> +   if (!tmp) {
> +   mutex_unlock(>mutex);
> +   r = -ENOMEM;
> +   goto error_unreserve;
>   }
> -   spin_unlock(>status_lock);
> +   tmp->it.start = bo_va->it.start;
> +   tmp->it.last = bo_va->it.last;
> +   tmp->vm = vm;
> +   tmp->bo = radeon_bo_ref(bo_va->bo);
>
>   interval_tree_remove(_va->it, >va);
>   bo_va->it.start = 0;
>   bo_va->it.last = 0;
> +
> +   spin_lock(>status_lock);
> +   list_del_init(_va->vm_status);
> +   list_add(>vm_status, >freed);
> +   spin_unlock(>status_lock);
>   }
>
>   if (soffset || eoffset) {
> --
> 1.9.1
>
>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #285 from Kajzer  ---
(In reply to Michel Dänzer from comment #284)
> Those are standard symptoms of a GPU hang and failed reset. Those symptoms
> can be caused by an unlimited number of different problems. Since you're
> getting those symptoms under different circumstances than those described in
> this report, we have to assume it's a different problem.
> 
> Please don't make me ask you one more time to file your own report. Every
> comment we add here about your problem is cluttering up this report even
> more than it already is. Thanks for your understanding.

Sure, no problem.
I thought it was the same thing because it behaved like this problem.

Anyway, I made a new report, it's here :
https://bugs.freedesktop.org/show_bug.cgi?id=91268

-- 
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/20150708/76fd0a5e/attachment.html>

[Bug 91268] R6xx freezes with kernel 3.17 and up

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

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

Bug ID: 91268
   Summary: R6xx freezes with kernel 3.17 and up
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: kap3tan at gmail.com

Something was introduced in kernel 3.17 which makes my GPU to freeze while
playing games. When it happens screen freeze for a few seconds, then it goes
blank for a few seconds, then it comes back with strange artifacts on the
screen, system is basically unresponsive, the only thing you can do is a hard
reset.
With kernels below 3.17 this doesn't happen.
Mesa version also doesn't matter.
Basically same everything, just booting with different kernel makes a
difference.
3.16 is good and 3.17 is bad (also every other kernel above 3.17)
With kernel 3.16 I can play games for days/weeks and bug will not happen.
With 3.17 it can happen anywhere between 15 minutes and few hours.
I did a bisect and it produced this :

git bisect start '--' 'drivers/gpu/drm/radeon'
# good: [19583ca584d6f574384e17fe7613dfaeadcdc4a6] Linux 3.16
git bisect good 19583ca584d6f574384e17fe7613dfaeadcdc4a6
# bad: [bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9] Linux 3.17
git bisect bad bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9
# bad: [03f62abd112d5150b6ce8957fa85d4f6e85e357f] drm/radeon: split PT setup in
more functions
git bisect bad 03f62abd112d5150b6ce8957fa85d4f6e85e357f
# bad: [391bfec33cd4e103274f197924d41ef648b849de] drm/radeon: remove visible
vram size limit on bo allocation (v4)
git bisect bad 391bfec33cd4e103274f197924d41ef648b849de
# good: [da9976206c15178eeae1b4445c9266125bf35b0a] drm/radeon: enable display
scaling on all connectors (v2)
git bisect good da9976206c15178eeae1b4445c9266125bf35b0a
# good: [380670aebfca998bb67b9cf05fc7f28ebeac4b18] drm/radeon: Demote 'BO
allocation size too large' message to debug only
git bisect good 380670aebfca998bb67b9cf05fc7f28ebeac4b18
# bad: [02376d8282b88f07d0716da6155094c8760b1a13] drm/radeon: Allow
write-combined CPU mappings of BOs in GTT (v2)
git bisect bad 02376d8282b88f07d0716da6155094c8760b1a13
# good: [77497f2735ad6e29c55475e15e9790dbfa2c2ef8] drm/radeon: Pass GART page
flags to radeon_gart_set_page() explicitly
git bisect good 77497f2735ad6e29c55475e15e9790dbfa2c2ef8
# first bad commit: [02376d8282b88f07d0716da6155094c8760b1a13] drm/radeon:
Allow write-combined CPU mappings of BOs in GTT (v2)

commit 02376d8282b88f07d0716da6155094c8760b1a13
Author: Michel Dänzer 
Date:   Thu Jul 17 19:01:08 2014 +0900

drm/radeon: Allow write-combined CPU mappings of BOs in GTT (v2)

v2: fix rebase onto drm-fixes

Signed-off-by: Michel Dänzer 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 

Currently I'm running kernel with commit before the first bad one :
$ git reset --hard 77497f2735ad6e29c55475e15e9790dbfa2c2ef8
HEAD is now at 77497f2 drm/radeon: Pass GART page flags to
radeon_gart_set_page() explicitly

to test it more thoroughly and see if hang will occur.

-- 
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/20150708/1d53f38b/attachment.html>

[PATCH 1/2] drm/radeon: allways add the VM clear duplicate

[Alex Deucher]

On Wed, Jul 8, 2015 at 12:08 PM, Christian König
 wrote:
> On 08.07.2015 17:57, Alex Deucher wrote:
>>
>> On Wed, Jul 8, 2015 at 3:56 AM, Christian König 
>> wrote:
>>>
>>> From: Christian König 
>>>
>>> We need to allways add the VM clear duplicate of the BO_VA,
>>> no matter what the old status was.
>>>
>>> Signed-off-by: Christian König 
>>> Test-by: hadack at gmx.de
>>
>> This patch does not apply cleanly.  It also adds an undefined label
>> error_unreserve.  Is there an additional patch required?
>
>
> That's possible, but I thought the depending patch would have already been
> upstream.
>
> Can you create a drm-fixes-4.2 branch I can rebase on?

http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.2-wip

Thanks,

Alex

>
> Thanks,
> Christian.
>
>
>> Alex
>>
>>> ---
>>>   drivers/gpu/drm/radeon/radeon_vm.c | 34
>>> --
>>>   1 file changed, 16 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c
>>> b/drivers/gpu/drm/radeon/radeon_vm.c
>>> index ec10533..0310965 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_vm.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
>>> @@ -493,29 +493,27 @@ int radeon_vm_bo_set_addr(struct radeon_device
>>> *rdev,
>>>  }
>>>
>>>  if (bo_va->it.start || bo_va->it.last) {
>>> -   spin_lock(>status_lock);
>>> -   if (list_empty(_va->vm_status)) {
>>> -   /* add a clone of the bo_va to clear the old
>>> address */
>>> -   struct radeon_bo_va *tmp;
>>> -   spin_unlock(>status_lock);
>>> -   tmp = kzalloc(sizeof(struct radeon_bo_va),
>>> GFP_KERNEL);
>>> -   if (!tmp) {
>>> -   mutex_unlock(>mutex);
>>> -   r = -ENOMEM;
>>> -   goto error_unreserve;
>>> -   }
>>> -   tmp->it.start = bo_va->it.start;
>>> -   tmp->it.last = bo_va->it.last;
>>> -   tmp->vm = vm;
>>> -   tmp->bo = radeon_bo_ref(bo_va->bo);
>>> -   spin_lock(>status_lock);
>>> -   list_add(>vm_status, >freed);
>>> +   /* add a clone of the bo_va to clear the old address */
>>> +   struct radeon_bo_va *tmp;
>>> +   tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
>>> +   if (!tmp) {
>>> +   mutex_unlock(>mutex);
>>> +   r = -ENOMEM;
>>> +   goto error_unreserve;
>>>  }
>>> -   spin_unlock(>status_lock);
>>> +   tmp->it.start = bo_va->it.start;
>>> +   tmp->it.last = bo_va->it.last;
>>> +   tmp->vm = vm;
>>> +   tmp->bo = radeon_bo_ref(bo_va->bo);
>>>
>>>  interval_tree_remove(_va->it, >va);
>>>  bo_va->it.start = 0;
>>>  bo_va->it.last = 0;
>>> +
>>> +   spin_lock(>status_lock);
>>> +   list_del_init(_va->vm_status);
>>> +   list_add(>vm_status, >freed);
>>> +   spin_unlock(>status_lock);
>>>  }
>>>
>>>  if (soffset || eoffset) {
>>> --
>>> 1.9.1
>>>
>

[PATCH] drm/rockchip: use drm_gem_mmap helpers

[Mark yao]

On 2015年07月07日 20:04, Daniel Vetter wrote:
> On Tue, Jul 07, 2015 at 05:03:36PM +0800, Daniel Kurtz wrote:
>> Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
>> drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
>> routines.
>>
>> Once the core functions return successfully, the rockchip mmap routines
>> can still use dma_mmap_attrs() to simply mmap the entire buffer.
>>
>> [0] Previously, we were performing the mmap() without first taking a
>> reference on the underlying gem buffer.  This could leak ptes if the gem
>> object is destroyed while userspace is still holding the mapping.
>>
>> Signed-off-by: Daniel Kurtz 
>> Reviewed-by: Daniel Vetter 
>> Cc: stable at vger.kernel.org
> Applied to topic/drm-fixes to make sure it won't get lost, but I expect
> rockchip maintainers to pick this one up.
> -Daniel
I try to pick this patch up, but found it conflicts with patch [0].  Can 
you fix it?

[0]https://patchwork.kernel.org/patch/6226591/

-Mark
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 67 
>> +++--
>>   1 file changed, 34 insertions(+), 33 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>> index eb2282c..eba5f8a 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
>> @@ -54,55 +54,56 @@ static void rockchip_gem_free_buf(struct 
>> rockchip_gem_object *rk_obj)
>> _obj->dma_attrs);
>>   }
>>   
>> -int rockchip_gem_mmap_buf(struct drm_gem_object *obj,
>> -  struct vm_area_struct *vma)
>> +static int rockchip_drm_gem_object_mmap(struct drm_gem_object *obj,
>> +struct vm_area_struct *vma)
>> +
>>   {
>> +int ret;
>>  struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
>>  struct drm_device *drm = obj->dev;
>> -unsigned long vm_size;
>>   
>> -vma->vm_flags |= VM_IO | VM_DONTEXPAND | VM_DONTDUMP;
>> -vm_size = vma->vm_end - vma->vm_start;
>> -
>> -if (vm_size > obj->size)
>> -return -EINVAL;
>> +/*
>> + * dma_alloc_attrs() allocated a struct page table for rk_obj, so clear
>> + * VM_PFNMAP flag that was set by drm_gem_mmap_obj()/drm_gem_mmap().
>> + */
>> +vma->vm_flags &= ~VM_PFNMAP;
>>   
>> -return dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
>> +ret = dma_mmap_attrs(drm->dev, vma, rk_obj->kvaddr, rk_obj->dma_addr,
>>   obj->size, _obj->dma_attrs);
>> +if (ret)
>> +drm_gem_vm_close(vma);
>> +
>> +return ret;
>>   }
>>   
>> -/* drm driver mmap file operations */
>> -int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
>> +int rockchip_gem_mmap_buf(struct drm_gem_object *obj,
>> +  struct vm_area_struct *vma)
>>   {
>> -struct drm_file *priv = filp->private_data;
>> -struct drm_device *dev = priv->minor->dev;
>> -struct drm_gem_object *obj;
>> -struct drm_vma_offset_node *node;
>> +struct drm_device *drm = obj->dev;
>>  int ret;
>>   
>> -if (drm_device_is_unplugged(dev))
>> -return -ENODEV;
>> +mutex_lock(>struct_mutex);
>> +ret = drm_gem_mmap_obj(obj, obj->size, vma);
>> +mutex_unlock(>struct_mutex);
>> +if (ret)
>> +return ret;
>>   
>> -mutex_lock(>struct_mutex);
>> +return rockchip_drm_gem_object_mmap(obj, vma);
>> +}
>>   
>> -node = drm_vma_offset_exact_lookup(dev->vma_offset_manager,
>> -   vma->vm_pgoff,
>> -   vma_pages(vma));
>> -if (!node) {
>> -mutex_unlock(>struct_mutex);
>> -DRM_ERROR("failed to find vma node.\n");
>> -return -EINVAL;
>> -} else if (!drm_vma_node_is_allowed(node, filp)) {
>> -mutex_unlock(>struct_mutex);
>> -return -EACCES;
>> -}
>> +/* drm driver mmap file operations */
>> +int rockchip_gem_mmap(struct file *filp, struct vm_area_struct *vma)
>> +{
>> +struct drm_gem_object *obj;
>> +int ret;
>>   
>> -obj = container_of(node, struct drm_gem_object, vma_node);
>> -ret = rockchip_gem_mmap_buf(obj, vma);
>> +ret = drm_gem_mmap(filp, vma);
>> +if (ret)
>> +return ret;
>>   
>> -mutex_unlock(>struct_mutex);
>> +obj = vma->vm_private_data;
>>   
>> -return ret;
>> +return rockchip_drm_gem_object_mmap(obj, vma);
>>   }
>>   
>>   struct rockchip_gem_object *
>> -- 
>> 2.4.3.573.g4eafbef
>>


-- 
ï¼­ark

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/c1c0b165/attachment-0001.html>

[PATCH] drm/radeon: Report panel connector status as unknown when lid is closed

[Alex Deucher]

On Wed, Jul 8, 2015 at 4:24 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> This makes fbcon and desktop environments such as GNOME automatically
> not use the panel when the lid is closed.
>
> Signed-off-by: Michel Dänzer 

I've never really liked this approach.  The panel is still attached
then the lid is closed so it should still be reporting as attached.
Desktop environments look at the lid status anyway, it seems like they
should just use that rather than requiring the drivers jump through
hoops to tell them something they already know.

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_connectors.c | 82 
> --
>  1 file changed, 44 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index cebb65e..2484438 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -23,6 +23,7 @@
>   * Authors: Dave Airlie
>   *  Alex Deucher
>   */
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -890,25 +891,27 @@ radeon_lvds_detect(struct drm_connector *connector, 
> bool force)
> if (r < 0)
> return connector_status_disconnected;
>
> -   if (encoder) {
> -   struct radeon_encoder *radeon_encoder = 
> to_radeon_encoder(encoder);
> -   struct drm_display_mode *native_mode = 
> _encoder->native_mode;
> +   if (acpi_lid_open()) {
> +   if (encoder) {
> +   struct radeon_encoder *radeon_encoder = 
> to_radeon_encoder(encoder);
> +   struct drm_display_mode *native_mode = 
> _encoder->native_mode;
>
> -   /* check if panel is valid */
> -   if (native_mode->hdisplay >= 320 && native_mode->vdisplay >= 
> 240)
> -   ret = connector_status_connected;
> -   /* don't fetch the edid from the vbios if ddc fails and runpm 
> is
> -* enabled so we report disconnected.
> -*/
> -   if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm != 0))
> -   ret = connector_status_disconnected;
> -   }
> +   /* check if panel is valid */
> +   if (native_mode->hdisplay >= 320 && 
> native_mode->vdisplay >= 240)
> +   ret = connector_status_connected;
> +   /* don't fetch the edid from the vbios if ddc fails 
> and runpm is
> +* enabled so we report disconnected.
> +*/
> +   if ((rdev->flags & RADEON_IS_PX) && 
> (radeon_runtime_pm != 0))
> +   ret = connector_status_disconnected;
> +   }
>
> -   /* check for edid as well */
> -   radeon_connector_get_edid(connector);
> -   if (radeon_connector->edid)
> -   ret = connector_status_connected;
> -   /* check acpi lid status ??? */
> +   /* check for edid as well */
> +   radeon_connector_get_edid(connector);
> +   if (radeon_connector->edid)
> +   ret = connector_status_connected;
> +   } else
> +   ret = connector_status_unknown;
>
> radeon_connector_update_scratch_regs(connector, ret);
> pm_runtime_mark_last_busy(connector->dev->dev);
> @@ -1647,29 +1650,32 @@ radeon_dp_detect(struct drm_connector *connector, 
> bool force)
>
> if ((connector->connector_type == DRM_MODE_CONNECTOR_eDP) ||
> (connector->connector_type == DRM_MODE_CONNECTOR_LVDS)) {
> -   if (encoder) {
> -   struct radeon_encoder *radeon_encoder = 
> to_radeon_encoder(encoder);
> -   struct drm_display_mode *native_mode = 
> _encoder->native_mode;
> +   if (acpi_lid_open()) {
> +   if (encoder) {
> +   struct radeon_encoder *radeon_encoder = 
> to_radeon_encoder(encoder);
> +   struct drm_display_mode *native_mode = 
> _encoder->native_mode;
>
> -   /* check if panel is valid */
> -   if (native_mode->hdisplay >= 320 && 
> native_mode->vdisplay >= 240)
> +   /* check if panel is valid */
> +   if (native_mode->hdisplay >= 320 && 
> native_mode->vdisplay >= 240)
> +   ret = connector_status_connected;
> +   /* don't fetch the edid from the vbios if ddc 
> fails and runpm is
> +* enabled so we report disconnected.
> +*/
> +   if ((rdev->flags & RADEON_IS_PX) && 
> (radeon_runtime_pm != 0))
> +   ret = connector_status_disconnected;
> +   }
> + 

[PATCH 1/2] drm/radeon: allways add the VM clear duplicate

[Alex Deucher]

On Wed, Jul 8, 2015 at 3:56 AM, Christian König  
wrote:
> From: Christian König 
>
> We need to allways add the VM clear duplicate of the BO_VA,
> no matter what the old status was.
>
> Signed-off-by: Christian König 
> Test-by: hadack at gmx.de

This patch does not apply cleanly.  It also adds an undefined label
error_unreserve.  Is there an additional patch required?

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_vm.c | 34 --
>  1 file changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
> b/drivers/gpu/drm/radeon/radeon_vm.c
> index ec10533..0310965 100644
> --- a/drivers/gpu/drm/radeon/radeon_vm.c
> +++ b/drivers/gpu/drm/radeon/radeon_vm.c
> @@ -493,29 +493,27 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
> }
>
> if (bo_va->it.start || bo_va->it.last) {
> -   spin_lock(>status_lock);
> -   if (list_empty(_va->vm_status)) {
> -   /* add a clone of the bo_va to clear the old address 
> */
> -   struct radeon_bo_va *tmp;
> -   spin_unlock(>status_lock);
> -   tmp = kzalloc(sizeof(struct radeon_bo_va), 
> GFP_KERNEL);
> -   if (!tmp) {
> -   mutex_unlock(>mutex);
> -   r = -ENOMEM;
> -   goto error_unreserve;
> -   }
> -   tmp->it.start = bo_va->it.start;
> -   tmp->it.last = bo_va->it.last;
> -   tmp->vm = vm;
> -   tmp->bo = radeon_bo_ref(bo_va->bo);
> -   spin_lock(>status_lock);
> -   list_add(>vm_status, >freed);
> +   /* add a clone of the bo_va to clear the old address */
> +   struct radeon_bo_va *tmp;
> +   tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
> +   if (!tmp) {
> +   mutex_unlock(>mutex);
> +   r = -ENOMEM;
> +   goto error_unreserve;
> }
> -   spin_unlock(>status_lock);
> +   tmp->it.start = bo_va->it.start;
> +   tmp->it.last = bo_va->it.last;
> +   tmp->vm = vm;
> +   tmp->bo = radeon_bo_ref(bo_va->bo);
>
> interval_tree_remove(_va->it, >va);
> bo_va->it.start = 0;
> bo_va->it.last = 0;
> +
> +   spin_lock(>status_lock);
> +   list_del_init(_va->vm_status);
> +   list_add(>vm_status, >freed);
> +   spin_unlock(>status_lock);
> }
>
> if (soffset || eoffset) {
> --
> 1.9.1
>

[PATCH 2/3] drm/ttm: fix object deallocation to properly fill in the page pool.

[Michel Dänzer]

On 08.07.2015 02:41, Jerome Glisse wrote:
> On Tue, Jul 07, 2015 at 03:39:29PM +0900, Michel Dänzer wrote:
>> On 07.07.2015 01:10, Jerome Glisse wrote:
>>>
>>> In meantime i think we need to apply this patch as it is really a fix to
>>> make the code actually do what the comment and design pretends it does.
>>
>> I agree.
>>
>> BTW, maybe it should be split up into the actual fix (removing the
>> npages assignment) and the NUM_PAGES_TO_ALLOC related simplification?
> 
> This would make 2 really small patch, patch is small as it is :) But why
> not.

It's not about size but about having one commit for each logical change.
It took me a while to realize that the NUM_PAGES_TO_ALLOC changes aren't
directly related to the fix, and I've seen the same thing happen to others.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH:libdrm] include & directly for major() and minor()

[Alan Coopersmith]

On 07/ 8/15 10:59 AM, Emil Velikov wrote:
> On 8 July 2015 at 18:41, Alan Coopersmith  
> wrote:
>> Linux seems to pick these up via another header, but Solaris needs them
>> explictly included, or we get undefined symbol errors for major & minor.
>>
>> v2: use headers documented in makedev(3C) man page instead of sysmacros.h
>>
>> Signed-off-by: Alan Coopersmith 
>> ---
>>   libkms/linux.c |2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/libkms/linux.c b/libkms/linux.c
>> index 4d47148..53e03c3 100644
>> --- a/libkms/linux.c
>> +++ b/libkms/linux.c
>> @@ -40,6 +40,8 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>> +#include 
> I'll add the HAVE_SYS_MKDEV_H guard around the latter, and push this
> in the next few days. Unless someone objects that is ;-)

Oh, whoops, I forgot to check if there was a guard needed - that sounds
great to me, thanks.

-- 
-Alan Coopersmith-  alan.coopersmith at oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Daniel Vetter]

On Wed, Jul 08, 2015 at 10:00:22AM +0200, Maarten Lankhorst wrote:
> Op 07-07-15 om 18:43 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
> >> Op 07-07-15 om 14:10 schreef Daniel Vetter:
> >>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
>  Op 07-07-15 om 11:18 schreef Daniel Vetter:
> > On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
> >> This allows the first atomic call during hw init to be a real modeset,
> >> which is useful for forcing a recalculation.
> > fbcon is optional, you can't rely on anything being done in any specific
> > way. What exactly do you need this for, what's the implications?
>  In the hw readout I noticed some warnings when I wasn't setting any mode 
>  property in the readout.
>  I want the first function to be the modeset, so we have a sane base to 
>  commit changes on.
>  Ideally this whole function would have a atomic counterpart which does 
>  it in one go. :)
> >>> Yeah. Otoh as soon as we have atomic modeset working we can replace all
> >>> the legacy entry points with atomic helpers, and then even plane_disable
> >>> will be a full atomic modeset.
> >>>
> >>> What did fall apart with just touching properties/planes now?
> >> Also when i915 is fully atomic it calculates in 
> >> intel_modeset_compute_config
> >> if a modeset is needed after the first atomic call. Right now because
> >> intel_modeset_compute_config is only called in set_config so this works as 
> >> expected.
> >> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
> >> and if the final mode is different this will introduce a double modeset.
> > For expensive properties (i.e. a no-op changes causes something that takes
> > time like modeset or vblank wait) we need to make sure we filter them out
> > in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
> > the existing legacy set_prop functions should all filter out no-op changes
> > themselves. If we don't do that for rotation then that's a bug.
> >
> > Same for disabling planes harder, that shouldn't take time. Especially
> > since fbcon only force-disable non-primary plane, and for driver load
> > that's the exact thing we already do in the driver anyway.
> 
> Something like this?
> ---
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a1d4e13f3908..2989232f4996 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include "drm_crtc_internal.h"
>  #include 
>  
>  /**
> @@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc 
> *crtc,
>  {
>   struct drm_atomic_state *state;
>   struct drm_crtc_state *crtc_state;
> - int ret = 0;
> + uint64_t retval;
> + int ret;
> +
> + ret = drm_atomic_get_property(>base, property, );
> + if (!ret && val == retval)
> + return 0;
>  
>   state = drm_atomic_state_alloc(crtc->dev);
>   if (!state)
> @@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct drm_plane 
> *plane,
>  {
>   struct drm_atomic_state *state;
>   struct drm_plane_state *plane_state;
> - int ret = 0;
> + uint64_t retval;
> + int ret;
> +
> + ret = drm_atomic_get_property(>base, property, );
> + if (!ret && val == retval)
> + return 0;
>  
>   state = drm_atomic_state_alloc(plane->dev);
>   if (!state)
> @@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct 
> drm_connector *connector,
>  {
>   struct drm_atomic_state *state;
>   struct drm_connector_state *connector_state;
> - int ret = 0;
> + uint64_t retval;
> + int ret;
> +
> + ret = drm_atomic_get_property(>base, property, );
> + if (!ret && val == retval)
> + return 0;
>  
>   state = drm_atomic_state_alloc(connector->dev);
>   if (!state)

The reason I didn't do this is that a prop change might still result in no
hw state change (e.g. if you go automitic->explicit setting matching
automatic one). Hence I think we need to solve this in lower levels
anyway, i.e. in when computing the config. But it shouldn't cause trouble
yet.

> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 424c83323aaa..5bab7bff8a15 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1327,7 +1327,8 @@ void drm_plane_force_disable(struct drm_plane *plane)
>  {
>   int ret;
>  
> - if (!plane->fb)
> + if ((plane->state && !plane->state->fb) ||
> + (!plane->state && !plane->fb))
>   return;

Nah, atomic helpers should figure this out imo. Since if userspace does
the same (loop over all planes) then it won't go through force_disable.
-Daniel

>  
>   plane->old_fb = plane->fb;
> 

-- 
Daniel Vetter
Software Engineer, Intel 

[PATCH:libdrm] include & directly for major() and minor()

[Alan Coopersmith]

Linux seems to pick these up via another header, but Solaris needs them
explictly included, or we get undefined symbol errors for major & minor.

v2: use headers documented in makedev(3C) man page instead of sysmacros.h

Signed-off-by: Alan Coopersmith 
---
 libkms/linux.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libkms/linux.c b/libkms/linux.c
index 4d47148..53e03c3 100644
--- a/libkms/linux.c
+++ b/libkms/linux.c
@@ -40,6 +40,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 #include "libdrm_macros.h"
 #include "internal.h"
-- 
1.7.9.2

[PATCH:libdrm] include directly for major() and minor()

[Alan Coopersmith]

On 07/ 8/15 09:19 AM, Emil Velikov wrote:
> Hi Alan
>
> On 7 July 2015 at 01:45, Alan Coopersmith  
> wrote:
>> Linux seems to pick this up via another header, but Solaris needs it
>> explictly included, or we get undefined symbol errors for major & minor.
>>
> A slightly pedandic suggestion:
> Can we use sys/types.h + sys/mkdev.h as the manpage suggests. We
> already do so in xf86drm.c

Sure - I'd thought sysmacros.h was mentioned in a manpage, but can't find that 
now.  It builds fine with those instead, so v2 patch follows.

-- 
-Alan Coopersmith-  alan.coopersmith at oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc

[Bug 91263] R600 Segfault in finalize_textures

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

.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/3ac1d53d/attachment.html>

[Intel-gfx] [PATCH v2 02/20] drm: Don't update plane properties for atomic planes if it stays the same

[Maarten Lankhorst]

Op 07-07-15 om 18:43 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 05:08:34PM +0200, Maarten Lankhorst wrote:
>> Op 07-07-15 om 14:10 schreef Daniel Vetter:
>>> On Tue, Jul 07, 2015 at 12:20:10PM +0200, Maarten Lankhorst wrote:
 Op 07-07-15 om 11:18 schreef Daniel Vetter:
> On Tue, Jul 07, 2015 at 09:08:13AM +0200, Maarten Lankhorst wrote:
>> This allows the first atomic call during hw init to be a real modeset,
>> which is useful for forcing a recalculation.
> fbcon is optional, you can't rely on anything being done in any specific
> way. What exactly do you need this for, what's the implications?
 In the hw readout I noticed some warnings when I wasn't setting any mode 
 property in the readout.
 I want the first function to be the modeset, so we have a sane base to 
 commit changes on.
 Ideally this whole function would have a atomic counterpart which does it 
 in one go. :)
>>> Yeah. Otoh as soon as we have atomic modeset working we can replace all
>>> the legacy entry points with atomic helpers, and then even plane_disable
>>> will be a full atomic modeset.
>>>
>>> What did fall apart with just touching properties/planes now?
>> Also when i915 is fully atomic it calculates in intel_modeset_compute_config
>> if a modeset is needed after the first atomic call. Right now because
>> intel_modeset_compute_config is only called in set_config so this works as 
>> expected.
>> Otherwise drm_plane_force_disable or rotate_0 will force a modeset,
>> and if the final mode is different this will introduce a double modeset.
> For expensive properties (i.e. a no-op changes causes something that takes
> time like modeset or vblank wait) we need to make sure we filter them out
> in atomic_check. Yeah not quite there yet with pure atomic, but meanwhile
> the existing legacy set_prop functions should all filter out no-op changes
> themselves. If we don't do that for rotation then that's a bug.
>
> Same for disabling planes harder, that shouldn't take time. Especially
> since fbcon only force-disable non-primary plane, and for driver load
> that's the exact thing we already do in the driver anyway.

Something like this?
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index a1d4e13f3908..2989232f4996 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include "drm_crtc_internal.h"
 #include 

 /**
@@ -1716,7 +1717,12 @@ drm_atomic_helper_crtc_set_property(struct drm_crtc 
*crtc,
 {
struct drm_atomic_state *state;
struct drm_crtc_state *crtc_state;
-   int ret = 0;
+   uint64_t retval;
+   int ret;
+
+   ret = drm_atomic_get_property(>base, property, );
+   if (!ret && val == retval)
+   return 0;

state = drm_atomic_state_alloc(crtc->dev);
if (!state)
@@ -1776,7 +1782,12 @@ drm_atomic_helper_plane_set_property(struct drm_plane 
*plane,
 {
struct drm_atomic_state *state;
struct drm_plane_state *plane_state;
-   int ret = 0;
+   uint64_t retval;
+   int ret;
+
+   ret = drm_atomic_get_property(>base, property, );
+   if (!ret && val == retval)
+   return 0;

state = drm_atomic_state_alloc(plane->dev);
if (!state)
@@ -1836,7 +1847,12 @@ drm_atomic_helper_connector_set_property(struct 
drm_connector *connector,
 {
struct drm_atomic_state *state;
struct drm_connector_state *connector_state;
-   int ret = 0;
+   uint64_t retval;
+   int ret;
+
+   ret = drm_atomic_get_property(>base, property, );
+   if (!ret && val == retval)
+   return 0;

state = drm_atomic_state_alloc(connector->dev);
if (!state)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 424c83323aaa..5bab7bff8a15 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1327,7 +1327,8 @@ void drm_plane_force_disable(struct drm_plane *plane)
 {
int ret;

-   if (!plane->fb)
+   if ((plane->state && !plane->state->fb) ||
+   (!plane->state && !plane->fb))
return;

plane->old_fb = plane->fb;

[PATCH 03/12] drm/i915: Attach color properties to CRTC

[Malladi, Kausal]

On Wednesday 08 July 2015 04:53 AM, Matt Roper wrote:
> On Fri, Jul 03, 2015 at 09:01:38AM +0530, Kausal Malladi wrote:
>> This patch does the following:
>> 1. Adds new files intel_color_manager(.c/.h)
>> 2. Attaches color properties to CRTC while initialization
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Kausal Malladi 
>> ---
>>   drivers/gpu/drm/i915/Makefile  |  3 +-
>>   drivers/gpu/drm/i915/intel_color_manager.c | 61 
>> ++
>>   drivers/gpu/drm/i915/intel_color_manager.h | 28 ++
>>   drivers/gpu/drm/i915/intel_display.c   |  3 ++
>>   drivers/gpu/drm/i915/intel_drv.h   |  4 ++
>>   5 files changed, 98 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
>>   create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
>>
>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> index de21965..ad928d8 100644
>> --- a/drivers/gpu/drm/i915/Makefile
>> +++ b/drivers/gpu/drm/i915/Makefile
>> @@ -56,7 +56,8 @@ i915-y += intel_audio.o \
>>intel_overlay.o \
>>intel_psr.o \
>>intel_sideband.o \
>> -  intel_sprite.o
>> +  intel_sprite.o \
>> +  intel_color_manager.o
>>   i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
>>   i915-$(CONFIG_DRM_I915_FBDEV)  += intel_fbdev.o
>>   
>> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c 
>> b/drivers/gpu/drm/i915/intel_color_manager.c
>> new file mode 100644
>> index 000..9280ea6
>> --- /dev/null
>> +++ b/drivers/gpu/drm/i915/intel_color_manager.c
>> @@ -0,0 +1,61 @@
>> +/*
>> + * Copyright © 2015 Intel Corporation
>> + *
>> + * 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:
>> + * Shashank Sharma 
>> + * Kausal Malladi 
>> + */
>> +
>> +#include "intel_color_manager.h"
>> +
>> +void intel_color_manager_attach(struct drm_device *dev,
>> +struct drm_mode_object *mode_obj)
>> +{
>> +struct drm_mode_config *config = >mode_config;
>> +
>> +if (mode_obj->type == DRM_MODE_OBJECT_CRTC) {
> Is the expectation that this function will grow to include plane
> properties as well?  Personally I think it would be a little easier to
> read/follow if we had separate functions for attaching the crtc
> properties and the (eventual) plane properties, but it's not a huge
> deal.
Yes, it is expected to grow to include plane properties as well.
>
>> +if (config->prop_color_capabilities) {
>> +drm_object_attach_property(mode_obj,
>> +config->prop_color_capabilities, 0);
>> +DRM_DEBUG_DRIVER("Attached Color Caps property to 
>> CRTC\n");
>> +} else
>> +DRM_ERROR("Error attaching Color Capabilities property 
>> to CRTC\n");
>> +if (config->prop_palette_before_ctm) {
>> +drm_object_attach_property(mode_obj,
>> +config->prop_palette_before_ctm, 0);
>> +DRM_DEBUG_DRIVER("Attached Palette (before CTM) 
>> property to CRTC\n");
>> +} else
>> +DRM_ERROR("Error attaching Palette (before CTM) 
>> property to CRTC\n");
>> +if (config->prop_palette_after_ctm) {
>> +drm_object_attach_property(mode_obj,
>> +config->prop_palette_after_ctm, 0);
>> +DRM_DEBUG_DRIVER("Attached Palette (after CTM) property 
>> to CRTC\n");
>> +} else
>> +DRM_ERROR("Error attaching Palette (after CTM) property 
>> to CRTC\n");
>> +if (config->prop_ctm) {
>> +drm_object_attach_property(mode_obj,
>> +config->prop_ctm, 0);
>> + 

[PATCH 02/12] drm: Create Color Management DRM properties

[Malladi, Kausal]

Thanks for your review, Matt! Our responses inline...

Kausal

On Wednesday 08 July 2015 04:53 AM, Matt Roper wrote:
> On Fri, Jul 03, 2015 at 09:01:37AM +0530, Kausal Malladi wrote:
>> Color Management is an extension to Kernel display framework. It allows
>> abstraction of hardware color correction and enhancement capabilities by
>> virtue of DRM properties.
>>
>> This patch initializes color management framework by :
>> 1. Introducing new pointers in DRM mode_config structure to
>> carry CTM and Palette color correction properties.
>> 2. Creating these DRM properties in DRM standard properties creation
>> sequence.
>>
>> Signed-off-by: Shashank Sharma 
>> Signed-off-by: Kausal Malladi 
>> ---
>>   drivers/gpu/drm/drm_crtc.c | 24 
>>   include/drm/drm_crtc.h |  6 ++
>>   2 files changed, 30 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 2d57fc5..5d12ea9 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -1462,6 +1462,30 @@ static int drm_mode_create_standard_properties(struct 
>> drm_device *dev)
>>  return -ENOMEM;
>>  dev->mode_config.prop_mode_id = prop;
>>   
>> +/* Color Management properties */
>> +prop = drm_property_create(dev,
>> +DRM_MODE_PROP_BLOB | DRM_MODE_PROP_IMMUTABLE,
>> +"COLOR_CAPABILITIES", 0);
> Is there a specific reason you don't check for NULL on this property
> like you do on all the others, or is this just an oversight?
Oops, it was an oversight. Thanks for bringing it to notice.
>
>
> Matt
>
>> +dev->mode_config.prop_color_capabilities = prop;
>> +
>> +prop = drm_property_create(dev,
>> +DRM_MODE_PROP_BLOB, "PALETTE_AFTER_CTM", 0);
>> +if (!prop)
>> +return -ENOMEM;
>> +dev->mode_config.prop_palette_after_ctm = prop;
>> +
>> +prop = drm_property_create(dev,
>> +DRM_MODE_PROP_BLOB, "PALETTE_BEFORE_CTM", 0);
>> +if (!prop)
>> +return -ENOMEM;
>> +dev->mode_config.prop_palette_before_ctm = prop;
>> +
>> +prop = drm_property_create(dev,
>> +DRM_MODE_PROP_BLOB, "CTM", 0);
>> +if (!prop)
>> +return -ENOMEM;
>> +dev->mode_config.prop_ctm = prop;
>> +
>>  return 0;
>>   }
>>   
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 57ca8cc..408d39a 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -1178,6 +1178,12 @@ struct drm_mode_config {
>>  struct drm_property *suggested_x_property;
>>  struct drm_property *suggested_y_property;
>>   
>> +/* Color Management Properties */
>> +struct drm_property *prop_color_capabilities;
>> +struct drm_property *prop_palette_before_ctm;
>> +struct drm_property *prop_palette_after_ctm;
>> +struct drm_property *prop_ctm;
>> +
>>  /* dumb ioctl parameters */
>>  uint32_t preferred_depth, prefer_shadow;
>>   
>> -- 
>> 2.4.5
>>

[PATCH 2/2] drm/radeon: check if BO_VA is set before adding it to the invalidation list

[Christian König]

From: Christian König 

Otherwise we try to clear BO_VAs without an address.

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

Signed-off-by: Christian König 
Test-by: hadack at gmx.de
---
 drivers/gpu/drm/radeon/radeon_vm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 0310965..48d97c0 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -507,22 +507,21 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
tmp->bo = radeon_bo_ref(bo_va->bo);

interval_tree_remove(_va->it, >va);
+   spin_lock(>status_lock);
bo_va->it.start = 0;
bo_va->it.last = 0;
-
-   spin_lock(>status_lock);
list_del_init(_va->vm_status);
list_add(>vm_status, >freed);
spin_unlock(>status_lock);
}

if (soffset || eoffset) {
+   spin_lock(>status_lock);
bo_va->it.start = soffset;
bo_va->it.last = eoffset - 1;
-   interval_tree_insert(_va->it, >va);
-   spin_lock(>status_lock);
list_add(_va->vm_status, >cleared);
spin_unlock(>status_lock);
+   interval_tree_insert(_va->it, >va);
}

bo_va->flags = flags;
@@ -1156,7 +1155,8 @@ void radeon_vm_bo_invalidate(struct radeon_device *rdev,

list_for_each_entry(bo_va, >va, bo_list) {
spin_lock(_va->vm->status_lock);
-   if (list_empty(_va->vm_status))
+   if (list_empty(_va->vm_status) &&
+   (bo_va->it.start || bo_va->it.last))
list_add(_va->vm_status, _va->vm->invalidated);
spin_unlock(_va->vm->status_lock);
}
-- 
1.9.1

[PATCH 1/2] drm/radeon: allways add the VM clear duplicate

[Christian König]

From: Christian König 

We need to allways add the VM clear duplicate of the BO_VA,
no matter what the old status was.

Signed-off-by: Christian König 
Test-by: hadack at gmx.de
---
 drivers/gpu/drm/radeon/radeon_vm.c | 34 --
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index ec10533..0310965 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -493,29 +493,27 @@ int radeon_vm_bo_set_addr(struct radeon_device *rdev,
}

if (bo_va->it.start || bo_va->it.last) {
-   spin_lock(>status_lock);
-   if (list_empty(_va->vm_status)) {
-   /* add a clone of the bo_va to clear the old address */
-   struct radeon_bo_va *tmp;
-   spin_unlock(>status_lock);
-   tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
-   if (!tmp) {
-   mutex_unlock(>mutex);
-   r = -ENOMEM;
-   goto error_unreserve;
-   }
-   tmp->it.start = bo_va->it.start;
-   tmp->it.last = bo_va->it.last;
-   tmp->vm = vm;
-   tmp->bo = radeon_bo_ref(bo_va->bo);
-   spin_lock(>status_lock);
-   list_add(>vm_status, >freed);
+   /* add a clone of the bo_va to clear the old address */
+   struct radeon_bo_va *tmp;
+   tmp = kzalloc(sizeof(struct radeon_bo_va), GFP_KERNEL);
+   if (!tmp) {
+   mutex_unlock(>mutex);
+   r = -ENOMEM;
+   goto error_unreserve;
}
-   spin_unlock(>status_lock);
+   tmp->it.start = bo_va->it.start;
+   tmp->it.last = bo_va->it.last;
+   tmp->vm = vm;
+   tmp->bo = radeon_bo_ref(bo_va->bo);

interval_tree_remove(_va->it, >va);
bo_va->it.start = 0;
bo_va->it.last = 0;
+
+   spin_lock(>status_lock);
+   list_del_init(_va->vm_status);
+   list_add(>vm_status, >freed);
+   spin_unlock(>status_lock);
}

if (soffset || eoffset) {
-- 
1.9.1

R200 DRM/KMS

[Alex Deucher]

On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury  wrote:
>
>
> On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
>> On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury  
>> wrote:
>> >
>> >
>> > On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
>> >> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  
>> >> wrote:
>> >> >
>> >> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
>> >> > gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
>> >> > could be interfering but triggering a device "remove" before starting
>> >> > X made no difference.
>> >> >
>> >> > I'm a bit of a loss.  I suppose I could try writing a simple test for
>> >> > drmSetInterfaceVersion().  At least that should determine whether the
>> >> > xserver/ddx is in the clear.
>> >> >
>> >> > Any other ideas?
>> >> >
>> >>
>> >> Can you start a non-X runlevel and start X manually as root (assuming
>> >> you are using a login manager now)?
>> >>
>> > My test program worked fine. I considerably improved it over the version I 
>> > posted. I'll send it to the list when I get back.
>> >
>> > I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much 
>> > further.  Starting Xserver as root  apparently started normally, according 
>> > to the log, although  there was a permission denied error on mode set 
>> > during init. I don't know whether it was related or not, but the display 
>> > then hung with a non-blinking cursor. Strange to get a permission denied 
>> > as root!
>> >
>> > Starting GNOME via gdm gives a working slow X session but for some reason 
>> > only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. 
>> > Perhaps it's a config error somewhere.. ?
>> >
>> > startx as a regular user just works!
>> >
>> > But mutter doesn't, perhaps that's
>> > why a gnome session isn't working. It just gives the following error:
>> > Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
>> >
>> > Mutter is supposed to work on r200, right?
>>
>> IIRC it tries to use a render buffer format that's not supported by the hw.
> Is there anything to be done about it? Have to use a different wm/compositor?
>

Another wm or compositor may help.

> Any idea why removing the call from radeon_kms.c worked?

No idea.

Alex

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

[Michal Hocko]

On Wed 08-07-15 09:32:18, Daniel Vetter wrote:
[...]
> Ok that's starting to get nasty. Can you please test what happens when you
> boot with drm.vblankoffdelay=0 and whether drm.vblankoffdelay=1000 has an
> effect on reproduction rate? No debug output needed.

No difference. See the kernel log from both runs attached.
-- 
Michal Hocko
SUSE Labs
-- next part --
A non-text attachment was scrubbed...
Name: log.gz
Type: application/gzip
Size: 32451 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/53a17225/attachment-0001.bin>

[PATCH] drm/rockchip: use drm_gem_mmap helpers

[Daniel Vetter]

On Wed, Jul 08, 2015 at 12:06:53PM +0800, Mark yao wrote:
> On 2015年07月07日 20:04, Daniel Vetter wrote:
> >On Tue, Jul 07, 2015 at 05:03:36PM +0800, Daniel Kurtz wrote:
> >>Rather than (incompletely [0]) re-implementing drm_gem_mmap() and
> >>drm_gem_mmap_obj() helpers, call them directly from the rockchip mmap
> >>routines.
> >>
> >>Once the core functions return successfully, the rockchip mmap routines
> >>can still use dma_mmap_attrs() to simply mmap the entire buffer.
> >>
> >>[0] Previously, we were performing the mmap() without first taking a
> >>reference on the underlying gem buffer.  This could leak ptes if the gem
> >>object is destroyed while userspace is still holding the mapping.
> >>
> >>Signed-off-by: Daniel Kurtz 
> >>Reviewed-by: Daniel Vetter 
> >>Cc: stable at vger.kernel.org
> >Applied to topic/drm-fixes to make sure it won't get lost, but I expect
> >rockchip maintainers to pick this one up.
> >-Daniel
> I try to pick this patch up, but found it conflicts with patch [0].  Can you
> fix it?
> 
> [0]https://patchwork.kernel.org/patch/6226591/

Imo this should be the other way round since Daniel's patch fixes a fairly
serious issue: Apply this fix first, rebase the polish for -next.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

[Daniel Vetter]

On Wed, Jul 08, 2015 at 08:40:17AM +0200, Michal Hocko wrote:
> I have just tried to boot 4.2-rc1 and cannot seem to reproduce the issue
> anymore.
> 
> On Tue 07-07-15 10:43:58, Daniel Vetter wrote:
> [...]
> > Can you please
> > boot with drm.debug=0xf (lots more nois in dmesg with this) and reproduce?
> > I only need the last few pages before the WARNING backtrace, just to
> > understand a bit better what's going on there.
> 
> And 0xf debug level seem to paper over the problem because I do not see
> the warning even with 4.1 where I am able to reproduce this reliably.
> This suggests this is a timing sensitive issue.

Ok that's starting to get nasty. Can you please test what happens when you
boot with drm.vblankoffdelay=0 and whether drm.vblankoffdelay=1000 has an
effect on reproduction rate? No debug output needed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

R200 DRM/KMS

[Alex Deucher]

On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury  wrote:
>
>
> On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
>> On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury  
>> wrote:
>> >
>> > I've tried an xserver-1.16, and ddx, libdrm without LTO and with
>> > gcc4.9.  Exactly the same thing.  I wondered whether the unused i810
>> > could be interfering but triggering a device "remove" before starting
>> > X made no difference.
>> >
>> > I'm a bit of a loss.  I suppose I could try writing a simple test for
>> > drmSetInterfaceVersion().  At least that should determine whether the
>> > xserver/ddx is in the clear.
>> >
>> > Any other ideas?
>> >
>>
>> Can you start a non-X runlevel and start X manually as root (assuming
>> you are using a login manager now)?
>>
> My test program worked fine. I considerably improved it over the version I 
> posted. I'll send it to the list when I get back.
>
> I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much 
> further.  Starting Xserver as root  apparently started normally, according to 
> the log, although  there was a permission denied error on mode set during 
> init. I don't know whether it was related or not, but the display then hung 
> with a non-blinking cursor. Strange to get a permission denied as root!
>
> Starting GNOME via gdm gives a working slow X session but for some reason 
> only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. 
> Perhaps it's a config error somewhere.. ?
>
> startx as a regular user just works!
>
> But mutter doesn't, perhaps that's
> why a gnome session isn't working. It just gives the following error:
> Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
>
> Mutter is supposed to work on r200, right?

IIRC it tries to use a render buffer format that's not supported by the hw.

Alex

WARNING: CPU: 0 PID: 3634 at drivers/gpu/drm/drm_irq.c:1141 drm_wait_one_vblank

[Michal Hocko]

I have just tried to boot 4.2-rc1 and cannot seem to reproduce the issue
anymore.

On Tue 07-07-15 10:43:58, Daniel Vetter wrote:
[...]
> Can you please
> boot with drm.debug=0xf (lots more nois in dmesg with this) and reproduce?
> I only need the last few pages before the WARNING backtrace, just to
> understand a bit better what's going on there.

And 0xf debug level seem to paper over the problem because I do not see
the warning even with 4.1 where I am able to reproduce this reliably.
This suggests this is a timing sensitive issue.
-- 
Michal Hocko
SUSE Labs

[Bug 90360] [RV710/M92] GPU lockup caused by shader based MPEG2 decoding

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

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

--- Comment #6 from no.spam.to.me at ish.de ---
(In reply to Christian König from comment #4)
> Because of
> that we fall back to shader based MPEG2 decoding and that seems to crash the
> GPU.

Who is responsible for shader based MPEG2 decoding?

-- 
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/20150708/7340fa03/attachment.html>

Device enumeration support in libdrm

[Zhou, Jammy]

Hi Emil,

With our previous RFC patches to add interfaces to support GPU device 
enumeration support in libdrm, the udev mechanism was used. But we found that 
if we introduce the libudev dependency for libdrm, there will be some problem 
to run steam application on recent distributions (for example, Ubuntu 14.04 
LTS) because of the conflict between the system libudev.so.1 (loaded by libdrm) 
and the libudev.so.0 (bundled in steam-runtime and loaded by steam 
application). There are some similar issues as mentioned in the links below. 
Although we can argue that it is application's problem, can we get rid of 
libudev for the device enumeration before Valve can make steam-runtime use 
system libraries by default? It is much appreciated if you can give some 
suggestions about how we can support device enumeration with libdrm.

https://wiki.debian.org/Steam
https://github.com/ValveSoftware/steam-runtime/issues/13

Regards,
Jammy

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/0d5e8e73/attachment-0001.html>

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

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

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

--- Comment #18 from Dave Witbrodt  ---
(In reply to Dave Witbrodt from comment #15)
[...]
> I have not yet tested suspend-to-RAM, but
> after the testing I've done so far I doubt there will be problems.

I tried suspend-to-RAM before leaving for work, and it resumed fine after work.
 No problems at all with the code in question.

DW

-- 
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/20150708/c645ca4a/attachment.html>

[Bug 91256] Xorg dies - monitor goes to black and after a few seconds came back

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

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/AMDgpu   |DRM/Radeon
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-team at lists.x.org   |

-- 
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/20150708/eabbe2b2/attachment.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #284 from Michel Dänzer  ---
(In reply to Kajzer from comment #274)
> (In reply to Michel Dänzer from comment #273)
> > The original description of this report says: "screen becomes blank after
> > grub trying to boot it". Please file your own report.
>  
> When it happens screen freeze for a few seconds, then it goes blank for a
> few seconds, then it comes back with strange artifacts on the screen, system
> is basically unresponsive, the only thing you can do is a hard reset.

Those are standard symptoms of a GPU hang and failed reset. Those symptoms can
be caused by an unlimited number of different problems. Since you're getting
those symptoms under different circumstances than those described in this
report, we have to assume it's a different problem.

Please don't make me ask you one more time to file your own report. Every
comment we add here about your problem is cluttering up this report even more
than it already is. Thanks for your understanding.

-- 
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/20150708/5c5b5716/attachment.html>

[Bug 36563] Unity locks up with latest xorg/mesa/dri/drm

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

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

Ernst Sjöstrand  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Ernst Sjöstrand  ---
Old stuff not an issue anymore.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 90042] Age of Wonders III gpu lockup

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

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

Ernst Sjöstrand  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Ernst Sjöstrand  ---
Works now!

Probably
http://cgit.freedesktop.org/mesa/mesa/commit/?id=97ec2c694fe568e375ec7a2b85c1acb1e4666b54
?

*** This bug has been marked as a duplicate of bug 73528 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

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

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

Ernst Sjöstrand  changed:

   What|Removed |Added

 CC||dawide2211 at gmail.com

--- Comment #39 from Ernst Sjöstrand  ---
*** Bug 90042 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: