[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)

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

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

--- Comment #55 from Alex Deucher  ---
Make sure you ddx has this patch:
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=c4ae0e2cbcc0e2ebf9f13ee92d59b5120254a1dc
Also try this kernel patch for eg/btc:
https://bugzilla.kernel.org/attachment.cgi?id=141741
or this one for cayman:
https://bugs.freedesktop.org/attachment.cgi?id=102082

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

[PATCH v2 0/9] Updated fence patch series

[Greg KH]

On Tue, Jul 01, 2014 at 12:57:02PM +0200, Maarten Lankhorst wrote:
> So after some more hacking I've moved dma-buf to its own subdirectory,
> drivers/dma-buf and applied the fence patches to its new place. I believe 
> that the
> first patch should be applied regardless, and the rest should be ready now.
> :-)
> 
> Changes to the fence api:
> - release_fence -> fence_release etc.
> - __fence_init -> fence_init
> - __fence_signal -> fence_signal_locked
> - __fence_is_signaled -> fence_is_signaled_locked
> - Changing BUG_ON to WARN_ON in fence_later, and return NULL if it triggers.
> 
> Android can expose fences to userspace. It's possible to make the new fence
> mechanism expose the same fences to userspace by changing sync_fence_create
> to take a struct fence instead of a struct sync_pt. No other change is needed,
> because only the fence parts of struct sync_pt are used. But because the
> userspace fences are a separate problem and I haven't really looked at it yet
> I feel it should stay in staging, for now.

Ok, that's reasonable.

At first glance, this all looks "sane" to me, any objection from anyone
if I merge this through my driver-core tree for 3.17?

thanks,

greg k-h

[PATCH 1/1] drm/bochs: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN

[David Herrmann]

Hi

On Tue, Jul 1, 2014 at 9:02 PM, Fabian Frederick  wrote:
> use mm.h definition
>
> Cc: David Airlie 
> Cc: David Herrmann 
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Fabian Frederick 

Hm, this is defined in mm.h and we include it via drmP.h, which is
weird, but ok.

Reviewed-by: David Herrmann 

Thanks
David

> ---
>  drivers/gpu/drm/bochs/bochs_mm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c 
> b/drivers/gpu/drm/bochs/bochs_mm.c
> index b9a695d..1728a1b 100644
> --- a/drivers/gpu/drm/bochs/bochs_mm.c
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> @@ -387,7 +387,7 @@ int bochs_gem_create(struct drm_device *dev, u32 size, 
> bool iskernel,
>
> *obj = NULL;
>
> -   size = ALIGN(size, PAGE_SIZE);
> +   size = PAGE_ALIGN(size);
> if (size == 0)
> return -EINVAL;
>
> --
> 1.9.1
>

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

[Darren Etheridge]

On 07/01/2014 06:39 PM, Guido Mart?nez wrote:
> On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote:
>> [snip]
>>
>> Otherwise I think this is a good and useful patch series.
> It that a Tested-by tag? :)

Sure - I would prefer that the WARN_ON was silenced when the tilcdc 
module is removed, but the series adds improvements over what is there 
now.  I have tested it across a few variants of AM335x boards and 
attached display hardware in both module form and built-in to the 
kernel, therefore:

Tested-by: Darren Etheridge 

>
> Thanks!
> Guido
>
>>
>> Darren
>>
>>> The first 7 patches are bug fixes which and should probably be applied
>>> in the stable trees. The last two are clean-ups.
>>>
>>>
>>> Resending this since I got no replies.
>>>
>>>
>>> Guido Mart?nez (9):
>>>drm/i2c: tda998x: move drm_i2c_encoder_destroy call
>>>drm/tilcdc: panel: fix dangling sysfs connector node
>>>drm/tilcdc: slave: fix dangling sysfs connector node
>>>drm/tilcdc: tfp410: fix dangling sysfs connector node
>>>drm/tilcdc: panel: fix leak when unloading the module
>>>drm/tilcdc: fix release order on exit
>>>drm/tilcdc: fix double kfree
>>>drm/tilcdc: remove submodule destroy calls
>>>drm/tilcdc: replace late_initcall with module_init
>>>
>>>   drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
>>>   drivers/gpu/drm/tilcdc/Module.symvers  |  0
>>>   drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +
>>>   drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
>>>   drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 39 
>>> +-
>>>   drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 27 +--
>>>   drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++---
>>>   7 files changed, 59 insertions(+), 60 deletions(-)
>>>   create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers
>>>
>

[Bug 80678] xrandr scaling / transform does not work with radeon

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

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

--- Comment #5 from Harald Judt  ---
Maybe I forgot to compile in support for xv then. One way or the other, scaling
doesn't work.

-- 
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/20140701/715bdb6b/attachment.html>

[Bug 73053] dpm hangs with BTC parts

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

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

--- Comment #32 from Juan Orti Alcaine  ---
(In reply to comment #31)
> Created attachment 102081 [details] [review]
> possible fix
> 
> Does this patch fix the issues?

Great! it works very well, I've been using it for an hour, playing 3D games
with no stability problems. The temperature also is 10-20 ?C lower than before.

This kernel is your branch drm-next-3.16 at commit
4366f3b5f5a971cf348c298716b2cb29aab6ef4f + patch 102081

-- 
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/20140701/c4cf5188/attachment.html>

[Bug 80678] xrandr scaling / transform does not work with radeon

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

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

--- Comment #4 from Alex Deucher  ---
(In reply to comment #2)
> No, it doesn't work with glamor either. Besides, I'd like to use EXA because
> of xv support.

glamor supports Xv as well.

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

[Bug 80678] xrandr scaling / transform does not work with radeon

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

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

--- Comment #3 from Harald Judt  ---
Created attachment 102098
  --> https://bugs.freedesktop.org/attachment.cgi?id=102098=edit
xrandr-verbose-glamor

xrandr --verbose output after applying above xrandr command

-- 
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/20140701/851bb915/attachment-0001.html>

[Bug 80678] xrandr scaling / transform does not work with radeon

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

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

--- Comment #2 from Harald Judt  ---
No, it doesn't work with glamor either. Besides, I'd like to use EXA because of
xv support.

Actually, I notice one difference after executing
xrandr --fb 1920x2400 --output HDMI-0 --mode 1920x1200 --scale-from 1920x2400

The vertical panel seems to stretch/extend to the new vertical size (2400).
However, the intended scaling doesn't get applied.

xrandr --verbose before and after this command shows no differences.

-- 
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/20140701/1d05cd6c/attachment.html>

[PATCH 1/1] drm/bochs: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN

[Fabian Frederick]

use mm.h definition

Cc: David Airlie 
Cc: David Herrmann 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Fabian Frederick 
---
 drivers/gpu/drm/bochs/bochs_mm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index b9a695d..1728a1b 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -387,7 +387,7 @@ int bochs_gem_create(struct drm_device *dev, u32 size, bool 
iskernel,

*obj = NULL;

-   size = ALIGN(size, PAGE_SIZE);
+   size = PAGE_ALIGN(size);
if (size == 0)
return -EINVAL;

-- 
1.9.1

[PATCH 1/1] drm/omap: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN

[Fabian Frederick]

use mm.h definition

Cc: David Airlie 
Cc: Tomi Valkeinen 
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Fabian Frederick 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 1388ca7..8068612 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -169,7 +169,7 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
fbdev->ywrap_enabled = priv->has_dmm && ywrap_enabled;
if (fbdev->ywrap_enabled) {
/* need to align pitch to page size if using DMM scrolling */
-   mode_cmd.pitches[0] = ALIGN(mode_cmd.pitches[0], PAGE_SIZE);
+   mode_cmd.pitches[0] = PAGE_ALIGN(mode_cmd.pitches[0]);
}

/* allocate backing bo */
-- 
1.9.1

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

[Guido Martínez]

Hi Dave,

did you take a look at this patchset? I foolishly missed adding you on
the To: header, so apologies for that in advance.

Thanks,

On Tue, Jun 17, 2014 at 11:17:02AM -0300, Guido Mart?nez wrote:
> The tilcdc driver could be compiled as a module, but was severely broken
> and could not be used as such. This patchset attempts to fix the issues
> preventing a proper load/unload of the module.
> 
> Issues included dangling sysfs nodes, dangling devices, memory leaks and
> a double kfree.
> 
> It now seems to be working ok. We have tested this by loading and
> unloading the driver repeteadly, with both panel and slave connectors
> and found no flaws.
> 
> There is still one warning left on tilcdc_crtc_destroy, caused by
> destroying the connector while still in an ON status. We don't know why
> this happens or why it's an issue, so we did not fix it.
> 
> The first 7 patches are bug fixes which and should probably be applied
> in the stable trees. The last two are clean-ups.
> 
> 
> Resending this since I got no replies.
> 
> 
> Guido Mart?nez (9):
>   drm/i2c: tda998x: move drm_i2c_encoder_destroy call
>   drm/tilcdc: panel: fix dangling sysfs connector node
>   drm/tilcdc: slave: fix dangling sysfs connector node
>   drm/tilcdc: tfp410: fix dangling sysfs connector node
>   drm/tilcdc: panel: fix leak when unloading the module
>   drm/tilcdc: fix release order on exit
>   drm/tilcdc: fix double kfree
>   drm/tilcdc: remove submodule destroy calls
>   drm/tilcdc: replace late_initcall with module_init
> 
>  drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
>  drivers/gpu/drm/tilcdc/Module.symvers  |  0
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +
>  drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 39 
> +-
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 27 +--
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++---
>  7 files changed, 59 insertions(+), 60 deletions(-)
>  create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers
> 
> -- 
> 2.0.0
> 

-- 
Guido Mart?nez, VanguardiaSur
www.vanguardiasur.com.ar

[PATCH/RESEND 0/9] drm: tilcdc driver fixes

[Guido Martínez]

On Fri, Jun 27, 2014 at 05:08:51PM -0500, Darren Etheridge wrote:
> [snip]
> 
> Otherwise I think this is a good and useful patch series.
It that a Tested-by tag? :)

Thanks!
Guido

> 
> Darren
> 
> >The first 7 patches are bug fixes which and should probably be applied
> >in the stable trees. The last two are clean-ups.
> >
> >
> >Resending this since I got no replies.
> >
> >
> >Guido Mart?nez (9):
> >   drm/i2c: tda998x: move drm_i2c_encoder_destroy call
> >   drm/tilcdc: panel: fix dangling sysfs connector node
> >   drm/tilcdc: slave: fix dangling sysfs connector node
> >   drm/tilcdc: tfp410: fix dangling sysfs connector node
> >   drm/tilcdc: panel: fix leak when unloading the module
> >   drm/tilcdc: fix release order on exit
> >   drm/tilcdc: fix double kfree
> >   drm/tilcdc: remove submodule destroy calls
> >   drm/tilcdc: replace late_initcall with module_init
> >
> >  drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
> >  drivers/gpu/drm/tilcdc/Module.symvers  |  0
> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c| 15 +
> >  drivers/gpu/drm/tilcdc/tilcdc_drv.h|  1 -
> >  drivers/gpu/drm/tilcdc/tilcdc_panel.c  | 39 
> > +-
> >  drivers/gpu/drm/tilcdc/tilcdc_slave.c  | 27 +--
> >  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 35 +++---
> >  7 files changed, 59 insertions(+), 60 deletions(-)
> >  create mode 100644 drivers/gpu/drm/tilcdc/Module.symvers
> >

-- 
Guido Mart?nez, VanguardiaSur
www.vanguardiasur.com.ar

[PATCH 1/1] drm/i915: replace ALIGN(PAGE_SIZE) by PAGE_ALIGN

[Fabian Frederick]

use mm.h definition

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx at lists.freedesktop.org
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Fabian Frederick 
---
 drivers/gpu/drm/i915/intel_display.c | 10 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5f285fb..f07cb83 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6116,8 +6116,8 @@ static void i9xx_get_plane_config(struct intel_crtc *crtc,
aligned_height = intel_align_height(dev, crtc->base.primary->fb->height,
plane_config->tiled);

-   plane_config->size = ALIGN(crtc->base.primary->fb->pitches[0] *
-  aligned_height, PAGE_SIZE);
+   plane_config->size = PAGE_ALIGN(crtc->base.primary->fb->pitches[0] *
+   aligned_height);

DRM_DEBUG_KMS("pipe/plane %d/%d with fb: size=%dx%d@%d, offset=%x, 
pitch %d, size 0x%x\n",
  pipe, plane, crtc->base.primary->fb->width,
@@ -7136,8 +7136,8 @@ static void ironlake_get_plane_config(struct intel_crtc 
*crtc,
aligned_height = intel_align_height(dev, crtc->base.primary->fb->height,
plane_config->tiled);

-   plane_config->size = ALIGN(crtc->base.primary->fb->pitches[0] *
-  aligned_height, PAGE_SIZE);
+   plane_config->size = PAGE_ALIGN(crtc->base.primary->fb->pitches[0] *
+   aligned_height);

DRM_DEBUG_KMS("pipe/plane %d/%d with fb: size=%dx%d@%d, offset=%x, 
pitch %d, size 0x%x\n",
  pipe, plane, crtc->base.primary->fb->width,
@@ -8233,7 +8233,7 @@ static u32
 intel_framebuffer_size_for_mode(struct drm_display_mode *mode, int bpp)
 {
u32 pitch = intel_framebuffer_pitch_for_width(mode->hdisplay, bpp);
-   return ALIGN(pitch * mode->vdisplay, PAGE_SIZE);
+   return PAGE_ALIGN(pitch * mode->vdisplay);
 }

 static struct drm_framebuffer *
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 088fe93..182fbc2 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -81,7 +81,7 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
  sizes->surface_depth);

size = mode_cmd.pitches[0] * mode_cmd.height;
-   size = ALIGN(size, PAGE_SIZE);
+   size = PAGE_ALIGN(size);
obj = i915_gem_object_create_stolen(dev, size);
if (obj == NULL)
obj = i915_gem_alloc_object(dev, size);
-- 
1.9.1

[Bug 70409] Discrete GPU fails to initialize and X segfaults on dual-GPU r600/radeonsi laptop

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

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

--- Comment #12 from Vitaliy Filippov  ---
OK, thanks. Everything works now, I'll post new bugs if I experience more
problems :)

-- 
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/20140701/ef1635f6/attachment.html>

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #76 from Luzipher  ---
(In reply to comment #75)
> > LLVM triggered Diagnostic Handler: unsupported call to function
> > llvm.AMDGPU.rsq. in main
> 
> You need to update your LLVM SVN/Git snapshot.

Just a quick update if someone else runs into this problem: llvm doesn't build
with gcc 4.7 or 4.9, but it works with gcc 4.8.3.

Other than that I didn't get different results from the newest git code (mesa,
xf86-video-ati) on a patched kernel 3.16-rc2 - egltri_screen works once,
eglgears_screen produces garbage. But it seems somewhat more stable (no
unrecoverable crashes as far as I can remember). Xorg on the other hand seems
worse (no output anymore), but that might be the new in-server glamor stuff, I
guess.

I won't be able to continue investigations for a few days - the printks are
still on my todo list (or maybe gdb ...).

-- 
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/20140701/2730fe7d/attachment.html>

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

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

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

--- Comment #114 from Marc  ---
I am trying the patch on kernel 3.15.0 (I modified line 1318). I'll give a
feedback in 24h.

-- 
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/20140701/99ee3616/attachment.html>

[PATCH] drm/radeon: add user pointer support v2

[Christian König]

Am 01.07.2014 17:35, schrieb Jerome Glisse:
> On Tue, Jul 01, 2014 at 11:49:18AM +0200, Christian K?nig wrote:
>> Am 30.06.2014 19:35, schrieb Jerome Glisse:
>>> On Mon, Jun 30, 2014 at 03:04:16PM +0200, Christian K?nig wrote:
>>>
>>> [SNIP]
>>> @@ -176,8 +181,15 @@ static int radeon_cs_parser_relocs(struct 
>>> radeon_cs_parser *p)
>>> if (p->cs_flags & RADEON_CS_USE_VM)
>>> p->vm_bos = radeon_vm_get_bos(p->rdev, p->ib.vm,
>>>   >validated);
>>> +   if (need_mmap_lock)
>>> +   down_read(>mm->mmap_sem);
>>> +
>>> +   r = radeon_bo_list_validate(p->rdev, >ticket, >validated, 
>>> p->ring);
>>> -   return radeon_bo_list_validate(p->rdev, >ticket, >validated, 
>>> p->ring);
>>> +   if (need_mmap_lock)
>>> +   up_read(>mm->mmap_sem);
>>> +
>>> +   return r;
>>>   }
>>> So the mmap lock protect almost nothing here. Once things are validated
>>> nothing forbid the userspace to unmap the range containing the user bo.
>> As far as I understand it (and I'm probably not so deep into the MM
>> code as you, so correct me if I'm wrong) unmapping the range would
>> result in an invalidate_range_start callback and this callback in
>> turn validates the BO into the CPU domain again. So it actually
>> blocks for the GPU operation to be completed, marks the pages in
>> question as dirty and then unpins them.
>>
>> This should protected us anything nasty to happen in the case of a
>> unmap(), fork() etc...
> Thing is nothing forbid from a new cs ioctl to happen right after
> the radeon range_start callback but before the core mm code that
> was about to do something. The mmap_sem will protect you from fork
> or munmap but not from otherthing.

Any suggestion on how to fix this?

I mean I could take the BO reservation in range_start and release it in 
range_end, but I'm pretty sure the code calling the MMU notifier won't 
like that.

[SNIP]
 +
 +static const struct mmu_notifier_ops radeon_bo_notifier = {
 +  .release = radeon_bo_mn_release,
 +  .invalidate_range_start = radeon_bo_mn_invalidate_range_start,
 +};
>>> What about invalidate_page callback ? You are breaking write back to
>>> disk. Which is not a welcome move.
>> Why? Keep in mind that the pages are pinned down as soon as we make
>> the first CS which uses them and marked as dirty when we are done
>> with them. In between those two events the page shouldn't be written
>> back to disk.
> Page could be dirty prior to be pin, or dirtied after being (CPU access).
> I am just pointing out that the GPU might be writting to the page while
> the page is use as source for disk I/O.

I still don't see the problem here, the worst thing that could happen is 
that we write a halve filled page to disk. But since we set the dirty 
bit again after the GPU is done with the pages it should be written back 
to disk again if necessary.

[SNIP]
> The biggest issue with it is the pining of memory, this violate the memcg.
> Direct-io pin memory but limit itself to a reasonable amount at a time.
> A GPU buffer object might be several hundred mega byte which obviously
> can be nasty from memory starvation point of view.

I thought we would handle this gracefully by accounting the memory 
pinned down to the GTT size as well. E.g. allocating GTT buffers pins 
down memory in the same way we would pin it down through this interface.

In the end the maximum amount of pinned down memory is always the GTT size.

Regards,
Christian.

>
> Most other issue can be worked out.
>
> Cheers,
> J?r?me
>

[PATCH 4/7] Exynos: add support for 'domain-always-on' property

[Tobias Jakobi]

Hi,


Marek Szyprowski wrote:
> Hello,
> 
> On 2014-07-01 10:52, Tobias Jakobi wrote:
>> Hello Marek,
>>
>> I think you had a similar patch in the tizen tree, but according to
>> Tomasz Figa, it was considered a hack. I don't quite see how this is
>> different.
>>
>> Also, if I have been following the discussion correctly, then the
>> powerdomain issue essentially is about the question which SoC block
>> needs the LCD0 domain and how the proper power on/off sequences should
>> look like.
>>
>> At least the mixer power issue, which I pointed out some time ago, seems
>> to be deal with now:
>> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-next=381be025ac1a6dc8efebdf146ced0d4a6007f77b
>>
> 
> Well, that patch solves power on/off sequence issue with mixer and hdmi,
> but it didn't solve the issue with additional managing of power domain
> on/off. You can check that if you remove always on property, system will
> freeze when hdmi cable is connected for the second time. I've investigated
> it for some time, but right now I didn't find any 100% reliable solution
> other than keeping the power domain enabled all the time. At least for
> now, this patch lets you use HDMI without any stability issues.
Hmm, I have also applied a similar hack to force TV and LCD0 pd on on my
system, but I didn't experience this behaviour (cable reconnecting).
Guess I have to recheck with some more recent tree to make sure.


> I've only found that there are still at least 2 issues with power domains.
> One is Mixer/Video Processor dependency on LCD0 domain, second is the
> proper
> power on/off sequence of HDMI/Mixer and TV domain. Forcing both domains to
> 'always on' workarounds both issues for now. Right now I have no better
> idea.
I had the impression that the patch from above, plus this one
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-next=245f98f269714c08dc6d66d021d166cf36059bc4
were supposed to fix these issues. I haven't tested them yet, because of
lack of time, but Rahul's patch appears to fix mixer poweroff, and
Inki's patch the sequencing (VP, Mixer and last but not least, the HDMI).


> Later, once the proper sequence is found we can remove those properties
> from Odroid DTS.
I dunno, because you would have to support the property to the end of
time then, even though it's not used anymore. Isn't that the kind of
thing that shouldn't end up in DT bindings specs?



> 
> Best regards


With best wishes,
Tobias

[PATCH 1/7] clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks

[Tobias Jakobi]

Hi,


Marek Szyprowski wrote:
> Hello,
> 
> On 2014-07-01 10:46, Tobias Jakobi wrote:
>> Hello Marek,
>>
>> I think this particular clock setup should already be handled by this
>> patch:
>> http://www.spinics.net/lists/arm-kernel/msg320013.html
>>
>> Or am I missing something here?
> 
> The patch you have pointed requires adding support for SET_PARENT_PARENT
> feature to clock core, which has not been accepted yet. Only then Exynod
> DRM drivers can be updated to correctly handle the changed clock tree.
I'm aware of this, but my point is: Wouldn't it be better to get the
SET_PARENT_PARENT upstream instead of applying a work-around (I am
assuming of course that SET_PARENT_PARENT is the correct way of handling
these clocks), which would be reverted later anyway?

Also this looks like similar to the work duplication issue that was
raised before here on the ml. Different groups working on the same
thing, but with no or little coordination between them. Might be just me
though...


> My approach is to introduce minimal changes and use the code which is
> already in the exynos drm/hdmi driver (it already manages 'mout_hdmi/mixer'
> clocks). If other solution is finally accepted, the code can be simplified
> and mout_hdmi/mixer clocks simply ignored. For now - my changes are needed
> to get HDMI output working and have least dependencies.
> 
> Best regards


With best wishes,
Tobias

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

[Dieter Nützel]

Am 01.07.2014 10:14, schrieb Michel D?nzer:
> From: Michel D?nzer 
> 
> But move the programming back to the vertical blank interrupt handler.
> And signal the flip as being completed immediately after programming it
> to the hardware.
> 
> This way we don't have to guess whether or not the hardware will 
> execute
> the flip in a given vertical blank period, avoiding a whole lot of
> trouble.
> 
> Also, not using the page flip interrupt anymore avoids problems due to
> completing page flips earlier than expected by userspace.
> 
> Signed-off-by: Michel D?nzer 

Michel,

against which tree is this first one?
Don't apply clean on 3.16-rc2.

Can't find this in 'my' source (radeon_display.c).

>>radeon_crtc->flip_status = RADEON_FLIP_SUBMITTED; <<<
 spin_unlock_irqrestore(>dev->event_lock, flags);
 up_read(>exclusive_lock);

Thanks,
Dieter

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

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

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

--- Comment #113 from Alexandre Demers  ---
Thanks Alex, I had seen this patch yesterday and I added it to my things to be
testes. I'll test it as soon as possible, but I still need to fix my kernel
build setup. I had to reinstall all my system a couple of weeks ago. I should
be able to test it in the next couple of days.

-- 
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/20140701/0257f9c7/attachment.html>

[PATCH] exynos: Put a stop to the userptr heresy.

[Inki Dae]

Hi Jerome,


On 2014? 07? 01? 06:46, j.glisse at gmail.com wrote:
> From: Jerome Glisse 
> 
> get_user_pages gives no garanty that page it returns are still
> the one backing the vma by the time it returns. Thus any ioctl

One of pages from get_user_pages() could be migrated? I think all the
pages are pinned so that they cannot be migrated. If not such case, is
there other case I missed?

One more thing, do you think this issue cannot be resolved so you are
trying to remove userptr feature from g2d driver?

Thanks,
Inki Dae

> that rely on this behavior is broken and rely on pure luck. To
> avoid any false hope from userspace stop such useage by simply
> flat out returning -EFAULT. Better to have a reliable behavior
> than to depend on pure luck and currently observed behavior of
> mm code.
> 
> Note this was not even compile tested but i think i did update
> all places.
> 
> Signed-off-by: J?r?me Glisse 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 277 
> +---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |  60 ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.h |  20 ---
>  4 files changed, 3 insertions(+), 355 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 36535f3..7b55e89 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -233,7 +233,6 @@ struct exynos_drm_g2d_private {
>   struct device   *dev;
>   struct list_headinuse_cmdlist;
>   struct list_headevent_list;
> - struct list_headuserptr_list;
>  };
>  
>  struct exynos_drm_ipp_private {
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 8001587..d0be6dc 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -118,9 +118,6 @@
>  #define G2D_CMDLIST_POOL_SIZE(G2D_CMDLIST_SIZE * 
> G2D_CMDLIST_NUM)
>  #define G2D_CMDLIST_DATA_NUM (G2D_CMDLIST_SIZE / sizeof(u32) - 2)
>  
> -/* maximum buffer pool size of userptr is 64MB as default */
> -#define MAX_POOL (64 * 1024 * 1024)
> -
>  enum {
>   BUF_TYPE_GEM = 1,
>   BUF_TYPE_USERPTR,
> @@ -185,19 +182,6 @@ struct drm_exynos_pending_g2d_event {
>   struct drm_exynos_g2d_event event;
>  };
>  
> -struct g2d_cmdlist_userptr {
> - struct list_headlist;
> - dma_addr_t  dma_addr;
> - unsigned long   userptr;
> - unsigned long   size;
> - struct page **pages;
> - unsigned intnpages;
> - struct sg_table *sgt;
> - struct vm_area_struct   *vma;
> - atomic_trefcount;
> - boolin_pool;
> - boolout_of_list;
> -};
>  struct g2d_cmdlist_node {
>   struct list_headlist;
>   struct g2d_cmdlist  *cmdlist;
> @@ -242,7 +226,6 @@ struct g2d_data {
>   struct kmem_cache   *runqueue_slab;
>  
>   unsigned long   current_pool;
> - unsigned long   max_pool;
>  };
>  
>  static int g2d_init_cmdlist(struct g2d_data *g2d)
> @@ -354,232 +337,6 @@ add_to_list:
>   list_add_tail(>event->base.link, _priv->event_list);
>  }
>  
> -static void g2d_userptr_put_dma_addr(struct drm_device *drm_dev,
> - unsigned long obj,
> - bool force)
> -{
> - struct g2d_cmdlist_userptr *g2d_userptr =
> - (struct g2d_cmdlist_userptr *)obj;
> -
> - if (!obj)
> - return;
> -
> - if (force)
> - goto out;
> -
> - atomic_dec(_userptr->refcount);
> -
> - if (atomic_read(_userptr->refcount) > 0)
> - return;
> -
> - if (g2d_userptr->in_pool)
> - return;
> -
> -out:
> - exynos_gem_unmap_sgt_from_dma(drm_dev, g2d_userptr->sgt,
> - DMA_BIDIRECTIONAL);
> -
> - exynos_gem_put_pages_to_userptr(g2d_userptr->pages,
> - g2d_userptr->npages,
> - g2d_userptr->vma);
> -
> - exynos_gem_put_vma(g2d_userptr->vma);
> -
> - if (!g2d_userptr->out_of_list)
> - list_del_init(_userptr->list);
> -
> - sg_free_table(g2d_userptr->sgt);
> - kfree(g2d_userptr->sgt);
> -
> - drm_free_large(g2d_userptr->pages);
> - kfree(g2d_userptr);
> -}
> -
> -static dma_addr_t *g2d_userptr_get_dma_addr(struct drm_device *drm_dev,
> - unsigned long userptr,
> - unsigned long size,
> - struct drm_file *filp,
> - unsigned long *obj)
> -{
> - struct drm_exynos_file_private 

[Bug 80419] XCOM: Enemy Unknown Causes lockup

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

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

--- Comment #32 from Alex  ---
FYI, have been running XCom happily using Mesa with Sandybridge (2500k, GPU
slightly overclocked to 1.4). I think this just affects Radeon.

-- 
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/20140701/2ee73bcf/attachment.html>

[PATCH] drm/exynos: Fix NULL pointer exception when suspending without components

[Inki Dae]

On 2014? 06? 30? 22:25, Krzysztof Kozlowski wrote:
> Fix a NULL pointer exception when main exynos drm driver was probed
> successfully but no components were added (e.g. by incomplete DTS). In
> such case the exynos_drm_load() is never called and drvdata is NULL.
> 

Right, it's good report. Applied.

Thanks,
Inki Dae


> The NULL pointer exception may theoretically also happen as a effect of race 
> between
> adding components and main driver: if suspend of the driver happens
> before adding components.
> 
> Trace:
> [1.190295] [drm] Initialized drm 1.1.0 20060810
> [1.195209] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully.
> (...)
> [   24.001743] PM: Syncing filesystems ... done.
> [   24.002177] Freezing user space processes ... (elapsed 0.000 seconds) done.
> [   24.007403] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
> done.
> [   24.032559] Unable to handle kernel NULL pointer dereference at virtual 
> address 0134
> [   24.035007] pgd = dedd8000
> [   24.037734] [0134] *pgd=5ee13831, *pte=, *ppte=
> [   24.043953] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [   24.049329] Modules linked in:
> [   24.052371] CPU: 0 PID: 1 Comm: sh Not tainted 
> 3.16.0-rc3-00035-geba20bbdde04-dirty #51
> [   24.060354] task: df478000 ti: df48 task.ti: df48
> [   24.065743] PC is at mutex_lock+0x10/0x50
> [   24.069733] LR is at drm_modeset_lock_all+0x30/0xbc
> [   24.074590] pc : []lr : []psr: a013
> [   24.074590] sp : df481db8  ip :   fp : c05e524c
> [   24.086045] r10: 0002  r9 : c02c1fe4  r8 : deca5e44
> [   24.091253] r7 :   r6 :   r5 : 014c  r4 : 0134
> [   24.097763] r3 :   r2 :   r1 :   r0 : 0134
> [   24.104275] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment 
> user
> [   24.111391] Control: 10c53c7d  Table: 5edd806a  DAC: 0015
> [   24.117120] Process sh (pid: 1, stack limit = 0xdf480240)
> [   24.122502] Stack: (0xdf481db8 to 0xdf482000)
> [   24.126843] 1da0:   
> dee01d80 c02a14b4
> [   24.135004] 1dc0:   c07aff98 c02aec7c 0002  
>  c07aff98
> [   24.143164] 1de0: deca5e10 c02aecf4 c02aecd4 c02c2010  c02c9470 
>  
> [   24.151322] 1e00:   deca5e10 deca5e10  c07aff98 
> 0002 deca5e44
> [   24.159482] 1e20: c06d8f78 c06fb800 deca5e78 c02ca660 df7baf00 007b0aa0 
> deca5e10 c06fb7c8
> [   24.167641] 1e40: c07aff98  0002 c02cbe18 9757aec5 0005 
> 9757aec5 0005
> [   24.175801] 1e60: ded1d380 0003 0003 c05c74d8 ded1d380 c07209d4 
> c05c7514 c07105d8
> [   24.183960] 1e80: 01e2a738 c0068a74  c05c7514 ded1d380 c071c6e0 
> 0004 c07105d8
> [   24.192119] 1ea0: 01e2a738 c047f1e0 c0600cc0 df481ec4 0003  
> 0003 c05c74d8
> [   24.200278] 1ec0: ded1d380 c071c6e0 c05c7514 c07105d8 01e2a738 c0069444 
> c06d905c 0003
> [   24.208438] 1ee0: 0003 ded1d380 c06d9064 0004 c05c3fc0 c0067d4c 
> df535ab0 ded1d380
> [   24.216596] 1f00: df481f80 ded1d380 0004 ded1d1cc ded1d1c0 c0221724 
> 0004 c016ca6c
> [   24.224756] 1f20: c016ca28   c016c1d4   
> b6f37000 df481f80
> [   24.232915] 1f40: decedd80 0004 df48 df48 b6f37000 c0110920 
> df47839c 6013
> [   24.241074] 1f60:   decedd80 decedd80 0004 df48 
> b6f37000 c0110da8
> [   24.249233] 1f80:   0004 b6edf5d8 0004 b6f37000 
> 0004 c000f2a8
> [   24.257393] 1fa0: 1000 c000f0e0 b6edf5d8 0004 0001 b6f37000 
> 0004 
> [   24.265551] 1fc0: b6edf5d8 0004 b6f37000 0004 0004 0001 
>  01e2a738
> [   24.273711] 1fe0:  beba0a20 b6e1f4f0 b6e7022c 6010 0001 
>  
> [   24.281885] [] (mutex_lock) from [] 
> (drm_modeset_lock_all+0x30/0xbc)
> [   24.289950] [] (drm_modeset_lock_all) from [] 
> (exynos_drm_suspend+0xc/0x64)
> [   24.298627] [] (exynos_drm_suspend) from [] 
> (exynos_drm_sys_suspend+0x20/0x34)
> [   24.307568] [] (exynos_drm_sys_suspend) from [] 
> (platform_pm_suspend+0x2c/0x54)
> [   24.316597] [] (platform_pm_suspend) from [] 
> (dpm_run_callback+0x48/0x170)
> [   24.325188] [] (dpm_run_callback) from [] 
> (__device_suspend+0x128/0x39c)
> [   24.333606] [] (__device_suspend) from [] 
> (dpm_suspend+0x5c/0x314)
> [   24.341506] [] (dpm_suspend) from [] 
> (suspend_devices_and_enter+0x8c/0x598)
> [   24.350185] [] (suspend_devices_and_enter) from [] 
> (pm_suspend+0x4c4/0x5d0)
> [   24.358862] [] (pm_suspend) from [] 
> (state_store+0x70/0xd4)
> [   24.366156] [] (state_store) from [] 
> (kobj_attr_store+0x14/0x20)
> [   24.373885] [] (kobj_attr_store) from [] 
> (sysfs_kf_write+0x44/0x48)
> [   24.381867] [] (sysfs_kf_write) from [] 
> (kernfs_fop_write+0xc0/0x17c)
> [   24.390027] [] (kernfs_fop_write) from [] 
> 

[PATCH 2/2] drm/radeon: Remove radeon_kms_pflip_irq_get/put()

[Michel Dänzer]

From: Michel D?nzer 

The vertical blank interrupt is already enabled/disabled via
drm_vblank_get/put(), so we only need to update the number of pending
page flips.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/radeon.h |  2 --
 drivers/gpu/drm/radeon/radeon_display.c |  5 ++--
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 52 -
 3 files changed, 2 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 7a45c93..e497ed5 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -769,8 +769,6 @@ int radeon_irq_kms_init(struct radeon_device *rdev);
 void radeon_irq_kms_fini(struct radeon_device *rdev);
 void radeon_irq_kms_sw_irq_get(struct radeon_device *rdev, int ring);
 void radeon_irq_kms_sw_irq_put(struct radeon_device *rdev, int ring);
-void radeon_irq_kms_pflip_irq_get(struct radeon_device *rdev, int crtc);
-void radeon_irq_kms_pflip_irq_put(struct radeon_device *rdev, int crtc);
 void radeon_irq_kms_enable_afmt(struct radeon_device *rdev, int block);
 void radeon_irq_kms_disable_afmt(struct radeon_device *rdev, int block);
 void radeon_irq_kms_enable_hpd(struct radeon_device *rdev, unsigned hpd_mask);
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index e66323e..2c54483 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -325,7 +325,7 @@ void radeon_crtc_handle_flip(struct radeon_device *rdev, 
int crtc_id)

drm_vblank_put(rdev->ddev, radeon_crtc->crtc_id);
radeon_fence_unref(>fence);
-   radeon_irq_kms_pflip_irq_put(rdev, work->crtc_id);
+   atomic_dec(>irq.pflip[radeon_crtc->crtc_id]);
queue_work(radeon_crtc->flip_queue, >unpin_work);
 }

@@ -435,8 +435,7 @@ static void radeon_flip_work_func(struct work_struct 
*__work)
/* We borrow the event spin lock for protecting flip_work */
spin_lock_irqsave(>dev->event_lock, flags);

-   /* set the proper interrupt */
-   radeon_irq_kms_pflip_irq_get(rdev, radeon_crtc->crtc_id);
+   atomic_inc(>irq.pflip[radeon_crtc->crtc_id]);

work->base = base;
radeon_crtc->flip_status = RADEON_FLIP_SUBMITTED;
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 089c9ff..8633f82 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -366,58 +366,6 @@ void radeon_irq_kms_sw_irq_put(struct radeon_device *rdev, 
int ring)
 }

 /**
- * radeon_irq_kms_pflip_irq_get - enable pageflip interrupt
- *
- * @rdev: radeon device pointer
- * @crtc: crtc whose interrupt you want to enable
- *
- * Enables the pageflip interrupt for a specific crtc (all asics).
- * For pageflips we use the vblank interrupt source.
- */
-void radeon_irq_kms_pflip_irq_get(struct radeon_device *rdev, int crtc)
-{
-   unsigned long irqflags;
-
-   if (crtc < 0 || crtc >= rdev->num_crtc)
-   return;
-
-   if (!rdev->ddev->irq_enabled)
-   return;
-
-   if (atomic_inc_return(>irq.pflip[crtc]) == 1) {
-   spin_lock_irqsave(>irq.lock, irqflags);
-   radeon_irq_set(rdev);
-   spin_unlock_irqrestore(>irq.lock, irqflags);
-   }
-}
-
-/**
- * radeon_irq_kms_pflip_irq_put - disable pageflip interrupt
- *
- * @rdev: radeon device pointer
- * @crtc: crtc whose interrupt you want to disable
- *
- * Disables the pageflip interrupt for a specific crtc (all asics).
- * For pageflips we use the vblank interrupt source.
- */
-void radeon_irq_kms_pflip_irq_put(struct radeon_device *rdev, int crtc)
-{
-   unsigned long irqflags;
-
-   if (crtc < 0 || crtc >= rdev->num_crtc)
-   return;
-
-   if (!rdev->ddev->irq_enabled)
-   return;
-
-   if (atomic_dec_and_test(>irq.pflip[crtc])) {
-   spin_lock_irqsave(>irq.lock, irqflags);
-   radeon_irq_set(rdev);
-   spin_unlock_irqrestore(>irq.lock, irqflags);
-   }
-}
-
-/**
  * radeon_irq_kms_enable_afmt - enable audio format change interrupt
  *
  * @rdev: radeon device pointer
-- 
2.0.0

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

[Michel Dänzer]

From: Michel D?nzer 

But move the programming back to the vertical blank interrupt handler.
And signal the flip as being completed immediately after programming it
to the hardware.

This way we don't have to guess whether or not the hardware will execute
the flip in a given vertical blank period, avoiding a whole lot of
trouble.

Also, not using the page flip interrupt anymore avoids problems due to
completing page flips earlier than expected by userspace.

Signed-off-by: Michel D?nzer 
---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 28 ---
 drivers/gpu/drm/radeon/cik.c| 58 +++---
 drivers/gpu/drm/radeon/evergreen.c  | 86 +
 drivers/gpu/drm/radeon/r100.c   | 48 +++---
 drivers/gpu/drm/radeon/r600.c   | 18 +--
 drivers/gpu/drm/radeon/radeon.h |  3 +-
 drivers/gpu/drm/radeon/radeon_asic.c| 22 -
 drivers/gpu/drm/radeon/radeon_asic.h|  4 --
 drivers/gpu/drm/radeon/radeon_display.c | 51 ++-
 drivers/gpu/drm/radeon/radeon_mode.h|  1 -
 drivers/gpu/drm/radeon/rs600.c  | 28 +++
 drivers/gpu/drm/radeon/rv770.c  | 24 ++---
 drivers/gpu/drm/radeon/si.c | 52 +++-
 13 files changed, 59 insertions(+), 364 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index e911898..65cfdbb 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1284,6 +1284,10 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
break;
}

+   /* Make sure updates happen at vertical blank */
+   WREG32(EVERGREEN_GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset, 0);
+   WREG32(EVERGREEN_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
+
WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + 
radeon_crtc->crtc_offset,
   upper_32_bits(fb_location));
WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + 
radeon_crtc->crtc_offset,
@@ -1321,15 +1325,6 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
WREG32(EVERGREEN_VIEWPORT_SIZE + radeon_crtc->crtc_offset,
   (viewport_w << 16) | viewport_h);

-   /* pageflip setup */
-   /* make sure flip is at vb rather than hb */
-   tmp = RREG32(EVERGREEN_GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset);
-   tmp &= ~EVERGREEN_GRPH_SURFACE_UPDATE_H_RETRACE_EN;
-   WREG32(EVERGREEN_GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset, tmp);
-
-   /* set pageflip to happen anywhere in vblank interval */
-   WREG32(EVERGREEN_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
-
if (!atomic && fb && fb != crtc->primary->fb) {
radeon_fb = to_radeon_framebuffer(fb);
rbo = gem_to_radeon_bo(radeon_fb->obj);
@@ -1360,7 +1355,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
uint64_t fb_location;
uint32_t fb_format, fb_pitch_pixels, tiling_flags;
u32 fb_swap = R600_D1GRPH_SWAP_ENDIAN_NONE;
-   u32 tmp, viewport_w, viewport_h;
+   u32 viewport_w, viewport_h;
int r;

/* no fb bound */
@@ -1451,6 +1446,10 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
else
WREG32(AVIVO_D2VGA_CONTROL, 0);

+   /* Make sure updates happen at vertical blank */
+   WREG32(AVIVO_D1GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset, 0);
+   WREG32(AVIVO_D1MODE_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
+
if (rdev->family >= CHIP_RV770) {
if (radeon_crtc->crtc_id) {
WREG32(R700_D2GRPH_PRIMARY_SURFACE_ADDRESS_HIGH, 
upper_32_bits(fb_location));
@@ -1490,15 +1489,6 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
WREG32(AVIVO_D1MODE_VIEWPORT_SIZE + radeon_crtc->crtc_offset,
   (viewport_w << 16) | viewport_h);

-   /* pageflip setup */
-   /* make sure flip is at vb rather than hb */
-   tmp = RREG32(AVIVO_D1GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset);
-   tmp &= ~AVIVO_D1GRPH_SURFACE_UPDATE_H_RETRACE_EN;
-   WREG32(AVIVO_D1GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset, tmp);
-
-   /* set pageflip to happen anywhere in vblank interval */
-   WREG32(AVIVO_D1MODE_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
-
if (!atomic && fb && fb != crtc->primary->fb) {
radeon_fb = to_radeon_framebuffer(fb);
rbo = gem_to_radeon_bo(radeon_fb->obj);
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 0f4b38f..d0a994c 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7143,25 +7143,6 @@ int cik_irq_set(struct radeon_device *rdev)
WREG32(LB_INTERRUPT_MASK + EVERGREEN_CRTC5_REGISTER_OFFSET, 
crtc6);
}

-   if (rdev->num_crtc >= 2) {
-   

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #54 from Alex Deucher  ---
(In reply to perry3d from comment #53)
> Hi Alex and Dieter,
> 
> i am using this patch since 5 min. So far i have no problems.
> Thank you!
> 
> What is the difference between vdcc and vdcci?

Two different voltages.  vddc is the core voltage.  vddci is the voltage
related to the memory interface.

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

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #53 from perry3d at gmail.com ---
Hi Alex and Dieter,

i am using this patch since 5 min. So far i have no problems.
Thank you!

What is the difference between vdcc and vdcci?

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

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

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

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

--- Comment #112 from Alex Deucher  ---
Created attachment 102082
  --> https://bugs.freedesktop.org/attachment.cgi?id=102082=edit
possible fix

Does this patch fix the issues?

-- 
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/20140701/2aca6d00/attachment.html>

[Bug 73053] dpm hangs with BTC parts

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

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

--- Comment #31 from Alex Deucher  ---
Created attachment 102081
  --> https://bugs.freedesktop.org/attachment.cgi?id=102081=edit
possible fix

Does this patch fix the issues?

-- 
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/20140701/62c1adef/attachment.html>

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #52 from Alex Deucher  ---
Created attachment 141741
  --> https://bugzilla.kernel.org/attachment.cgi?id=141741=edit
possible fix

Does this patch help?

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

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

--- Comment #51 from Alex Deucher  ---
Actually, You'd want to try the cypress patch for BTC parts.

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

[Bug 80684] I2C-over-AUX drops single bytes

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

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

--- Comment #2 from Alex Deucher  ---
Created attachment 102076
  --> https://bugs.freedesktop.org/attachment.cgi?id=102076=edit
possible fix

Does this patch help?

-- 
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/20140701/944e82ad/attachment.html>

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Michel Dänzer]

On 30.06.2014 16:43, Christian K?nig wrote:
> Am 30.06.2014 08:10, schrieb Michel D?nzer:
>> On 29.06.2014 19:34, Christian K?nig wrote:
>>> I've just pushed the branch testing-3.15 to
>>> git://people.freedesktop.org/~deathsimple/linux. It's based on 3.15.2
>>> and contains the "stop poisoning the GART TLB" patch backported to 3.15
>>> and a couple of things that I would like to try.
>> Running that branch, my Bonaire just survived a piglit run without
>> lockup. I hope that's an interesting result. :)
> 
> That's indeed an interesting result. Can you try to figure out which of
> the patches on the branch did the trick for you?

The winner is 'drm/radeon: completely over allocate PD and PTs'. That
patch alone on top of 3.15.2 makes piglit survive on my Bonaire.


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

[PATCH v3 4/8] drm: msm: update to use component match support

[Russell King]

Update MSM's DRM driver to use the component match support rather than
add_components.

Signed-off-by: Russell King 
---
This patch is destined for Greg's driver and David's DRM trees.

 drivers/gpu/drm/msm/msm_drv.c | 83 ++-
 1 file changed, 35 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9a5d87db5c23..a322029983ce 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -905,12 +905,41 @@ static int compare_of(struct device *dev, void *data)
 {
return dev->of_node == data;
 }
+#else
+static int compare_dev(struct device *dev, void *data)
+{
+   return dev == data;
+}
+#endif
+
+static int msm_drm_bind(struct device *dev)
+{
+   return drm_platform_init(_driver, to_platform_device(dev));
+}
+
+static void msm_drm_unbind(struct device *dev)
+{
+   drm_put_dev(platform_get_drvdata(to_platform_device(dev)));
+}
+
+static const struct component_master_ops msm_drm_ops = {
+   .bind = msm_drm_bind,
+   .unbind = msm_drm_unbind,
+};
+
+/*
+ * Platform driver:
+ */

-static int msm_drm_add_components(struct device *master, struct master *m)
+static int msm_pdev_probe(struct platform_device *pdev)
 {
-   struct device_node *np = master->of_node;
+   struct component_match *match = NULL;
+#ifdef CONFIG_OF
+   /* NOTE: the CONFIG_OF case duplicates the same code as exynos or imx
+* (or probably any other).. so probably some room for some helpers
+*/
+   struct device_node *np = pdev->dev.of_node;
unsigned i;
-   int ret;

for (i = 0; ; i++) {
struct device_node *node;
@@ -919,22 +948,9 @@ static int msm_drm_add_components(struct device *master, 
struct master *m)
if (!node)
break;

-   ret = component_master_add_child(m, compare_of, node);
-   of_node_put(node);
-
-   if (ret)
-   return ret;
+   component_match_add(>dev, , compare_of, node);
}
-   return 0;
-}
 #else
-static int compare_dev(struct device *dev, void *data)
-{
-   return dev == data;
-}
-
-static int msm_drm_add_components(struct device *master, struct master *m)
-{
/* For non-DT case, it kinda sucks.  We don't actually have a way
 * to know whether or not we are waiting for certain devices (or if
 * they are simply not present).  But for non-DT we only need to
@@ -958,41 +974,12 @@ static int msm_drm_add_components(struct device *master, 
struct master *m)
return -EPROBE_DEFER;
}

-   ret = component_master_add_child(m, compare_dev, dev);
-   if (ret) {
-   DBG("could not add child: %d", ret);
-   return ret;
-   }
+   component_match_add(>dev, , compare_dev, dev);
}
-
-   return 0;
-}
 #endif

-static int msm_drm_bind(struct device *dev)
-{
-   return drm_platform_init(_driver, to_platform_device(dev));
-}
-
-static void msm_drm_unbind(struct device *dev)
-{
-   drm_put_dev(platform_get_drvdata(to_platform_device(dev)));
-}
-
-static const struct component_master_ops msm_drm_ops = {
-   .add_components = msm_drm_add_components,
-   .bind = msm_drm_bind,
-   .unbind = msm_drm_unbind,
-};
-
-/*
- * Platform driver:
- */
-
-static int msm_pdev_probe(struct platform_device *pdev)
-{
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   return component_master_add(>dev, _drm_ops);
+   return component_master_add_with_match(>dev, _drm_ops, match);
 }

 static int msm_pdev_remove(struct platform_device *pdev)
-- 
1.8.3.1

[PATCH v3 4/8] drm: msm: update to use component match support

[Russell King]

Update MSM's DRM driver to use the component match support rather than
add_components.

Signed-off-by: Russell King 
---
This patch is destined for Greg's driver and David's DRM trees.

 drivers/gpu/drm/msm/msm_drv.c | 83 ++-
 1 file changed, 35 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9a5d87db5c23..a322029983ce 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -905,12 +905,41 @@ static int compare_of(struct device *dev, void *data)
 {
return dev->of_node == data;
 }
+#else
+static int compare_dev(struct device *dev, void *data)
+{
+   return dev == data;
+}
+#endif
+
+static int msm_drm_bind(struct device *dev)
+{
+   return drm_platform_init(_driver, to_platform_device(dev));
+}
+
+static void msm_drm_unbind(struct device *dev)
+{
+   drm_put_dev(platform_get_drvdata(to_platform_device(dev)));
+}
+
+static const struct component_master_ops msm_drm_ops = {
+   .bind = msm_drm_bind,
+   .unbind = msm_drm_unbind,
+};
+
+/*
+ * Platform driver:
+ */

-static int msm_drm_add_components(struct device *master, struct master *m)
+static int msm_pdev_probe(struct platform_device *pdev)
 {
-   struct device_node *np = master->of_node;
+   struct component_match *match = NULL;
+#ifdef CONFIG_OF
+   /* NOTE: the CONFIG_OF case duplicates the same code as exynos or imx
+* (or probably any other).. so probably some room for some helpers
+*/
+   struct device_node *np = pdev->dev.of_node;
unsigned i;
-   int ret;

for (i = 0; ; i++) {
struct device_node *node;
@@ -919,22 +948,9 @@ static int msm_drm_add_components(struct device *master, 
struct master *m)
if (!node)
break;

-   ret = component_master_add_child(m, compare_of, node);
-   of_node_put(node);
-
-   if (ret)
-   return ret;
+   component_match_add(>dev, , compare_of, node);
}
-   return 0;
-}
 #else
-static int compare_dev(struct device *dev, void *data)
-{
-   return dev == data;
-}
-
-static int msm_drm_add_components(struct device *master, struct master *m)
-{
/* For non-DT case, it kinda sucks.  We don't actually have a way
 * to know whether or not we are waiting for certain devices (or if
 * they are simply not present).  But for non-DT we only need to
@@ -958,41 +974,12 @@ static int msm_drm_add_components(struct device *master, 
struct master *m)
return -EPROBE_DEFER;
}

-   ret = component_master_add_child(m, compare_dev, dev);
-   if (ret) {
-   DBG("could not add child: %d", ret);
-   return ret;
-   }
+   component_match_add(>dev, , compare_dev, dev);
}
-
-   return 0;
-}
 #endif

-static int msm_drm_bind(struct device *dev)
-{
-   return drm_platform_init(_driver, to_platform_device(dev));
-}
-
-static void msm_drm_unbind(struct device *dev)
-{
-   drm_put_dev(platform_get_drvdata(to_platform_device(dev)));
-}
-
-static const struct component_master_ops msm_drm_ops = {
-   .add_components = msm_drm_add_components,
-   .bind = msm_drm_bind,
-   .unbind = msm_drm_unbind,
-};
-
-/*
- * Platform driver:
- */
-
-static int msm_pdev_probe(struct platform_device *pdev)
-{
pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-   return component_master_add(>dev, _drm_ops);
+   return component_master_add_with_match(>dev, _drm_ops, match);
 }

 static int msm_pdev_remove(struct platform_device *pdev)
-- 
1.8.3.1

[PATCH v3 0/8] component helper improvements

[Russell King - ARM Linux]

A while back, Laurent raised some comments about the component helper,
which this patch set starts to address.

The first point it addresses is the repeated parsing inefficiency when
deferred probing occurs.  When DT is used, the structure of the
component helper today means that masters end up parsing the device
tree for each attempt to re-bind the driver.

We remove this inefficiency by creating an array of matching data and
functions, which the component helper can use internally to match up
components to their master.

The second point was the inefficiency of destroying the list of
components each time we saw a failure.  We did this to ensure that
we kept things correctly ordered: component bind order matters.
As we have an array instead, the array is already ordered, so we
use this array to store the component pointers instead of a list,
and remember which are duplicates (and thus should be avoided.)
Avoiding the right duplicates matters as we walk the array in the
opposite direction at tear down.

I hope that this is the final submission in patch form.  Ultimately,
these patches need to be handled carefully:

Patch   Trees
1, 2, 3 Driver, Staging, DRM
4   Driver, DRM
5   Driver, Staging
6, 7, 8 To be held back until all users are updated (Exynos DRM)

 drivers/base/component.c   | 249 ++---
 drivers/gpu/drm/msm/msm_drv.c  |  83 +--
 drivers/staging/imx-drm/imx-drm-core.c |  57 +---
 include/linux/component.h  |   8 +-
 4 files changed, 208 insertions(+), 189 deletions(-)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

___
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[Bug 80531] 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]

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

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

--- Comment #12 from Alex Deucher  ---
Created attachment 102075
  --> https://bugs.freedesktop.org/attachment.cgi?id=102075=edit
add deep color module option

This patch disables the deep color support by default which should resolve your
issue.  You can set radeon.deep_color=1 on the kernel command line in grub to
re-enable it.  Hopefully we can resolve this properly for 3.17 and enable deep
color by default.

-- 
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/20140701/36140cd4/attachment.html>

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #22 from Sylvain BERTRAND  ---
additional info:
 - I did swap my TAHITI XT (7970) with a JUNIPER PRO (5750), the pixmap
transformation seems GPU bound since the tearing appears quite lower on JUNIPER
PRO than with TAHITI XT.

 - The vsync setting seems ignored by awesomenauts (does not change anything on
or off).

-- 
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/20140701/8a8bb142/attachment.html>

[PATCH RFC v2 3/8] component: add support for component match array

[Russell King - ARM Linux]

On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wrote:
> > Hi Russell,
> > 
> > On Tue, Jun 24, 2014 at 9:29 PM, Russell King
> >  wrote:
> > [...]
> > > +/*
> > > + * Add a component to be matched.
> > > + *
> > > + * The match array is first created or extended if necessary.
> > > + */
> > > +void component_match_add(struct device *dev, struct component_match 
> > > **matchptr,
> > > +   int (*compare)(struct device *, void *), void *compare_data)
> > > +{
> > > +   struct component_match *match = *matchptr;
> > > +
> > > +   if (IS_ERR(match))
> > > +   return;
> > > +
> > > +   if (!match || match->num == match->alloc) {
> > > +   size_t new_size = match ? match->alloc + 16 : 15;
> > > +
> > > +   match = component_match_realloc(dev, match, new_size);
> > > +
> > > +   *matchptr = match;
> > > +
> > > +   if (IS_ERR(match))
> > > +   return;
> > > +   }
> > > +
> > > +   match->compare[match->num].fn = compare;
> > > +   match->compare[match->num].data = compare_data;
> > > +   match->num++;
> > > +}
> > 
> > component_match_add should be exported.
> 
> Fixed, thanks.

As there's no further comments, and Inki Dae has not responded, I'm
going to send these out without the RFC tag in the hope that people
will provide acks.  This allows us to move forward with this despite
the Exynos DRM blockage.

The ultimate plan is for patches 1 to 3 inclusive to be merged into
Greg's driver tree, 1 to 3 and 5 into Greg's staging tree, and 1 to
3 and 4 for David Airlie's DRM tree - patches 1 to 3 are needed for
both patches 4 and 5.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[Bug 76998] hang on CEDAR right after log on

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

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

--- Comment #6 from Alex Deucher  ---
(In reply to comment #5)
> The result of the bisect is
> d4788db30a1a66255b592dd12613dda80c1443f7 is the first bad commit
> commit d4788db30a1a66255b592dd12613dda80c1443f7
> Author: Alex Deucher
> Date:   Thu Feb 28 14:40:09 2013 -0500
> 
> drm/radeon/evergreen: add support for golden register init
> 
> Signed-off-by: Alex Deucher

Do you think you could go through the golden register arrays for cedar and
narrow down which register(s) are problematic?

-- 
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/20140701/638b50fd/attachment.html>

[PATCH] drm/radeon: add user pointer support v2

[Jerome Glisse]

On Tue, Jul 01, 2014 at 08:14:47PM +0200, Christian K?nig wrote:
> Am 01.07.2014 17:35, schrieb Jerome Glisse:
> >On Tue, Jul 01, 2014 at 11:49:18AM +0200, Christian K?nig wrote:
> >>Am 30.06.2014 19:35, schrieb Jerome Glisse:
> >>>On Mon, Jun 30, 2014 at 03:04:16PM +0200, Christian K?nig wrote:
> >>>
> >>>[SNIP]
> >>>@@ -176,8 +181,15 @@ static int radeon_cs_parser_relocs(struct 
> >>>radeon_cs_parser *p)
> >>>   if (p->cs_flags & RADEON_CS_USE_VM)
> >>>   p->vm_bos = radeon_vm_get_bos(p->rdev, p->ib.vm,
> >>> >validated);
> >>>+  if (need_mmap_lock)
> >>>+  down_read(>mm->mmap_sem);
> >>>+
> >>>+  r = radeon_bo_list_validate(p->rdev, >ticket, >validated, 
> >>>p->ring);
> >>>-  return radeon_bo_list_validate(p->rdev, >ticket, >validated, 
> >>>p->ring);
> >>>+  if (need_mmap_lock)
> >>>+  up_read(>mm->mmap_sem);
> >>>+
> >>>+  return r;
> >>>  }
> >>>So the mmap lock protect almost nothing here. Once things are validated
> >>>nothing forbid the userspace to unmap the range containing the user bo.
> >>As far as I understand it (and I'm probably not so deep into the MM
> >>code as you, so correct me if I'm wrong) unmapping the range would
> >>result in an invalidate_range_start callback and this callback in
> >>turn validates the BO into the CPU domain again. So it actually
> >>blocks for the GPU operation to be completed, marks the pages in
> >>question as dirty and then unpins them.
> >>
> >>This should protected us anything nasty to happen in the case of a
> >>unmap(), fork() etc...
> >Thing is nothing forbid from a new cs ioctl to happen right after
> >the radeon range_start callback but before the core mm code that
> >was about to do something. The mmap_sem will protect you from fork
> >or munmap but not from otherthing.
> 
> Any suggestion on how to fix this?
> 
> I mean I could take the BO reservation in range_start and release it
> in range_end, but I'm pretty sure the code calling the MMU notifier
> won't like that.

I need to think a bit more about all the case other than munmap/fork
to see what might happen and under what circumstances.

> 
> [SNIP]
> +
> +static const struct mmu_notifier_ops radeon_bo_notifier = {
> + .release = radeon_bo_mn_release,
> + .invalidate_range_start = radeon_bo_mn_invalidate_range_start,
> +};
> >>>What about invalidate_page callback ? You are breaking write back to
> >>>disk. Which is not a welcome move.
> >>Why? Keep in mind that the pages are pinned down as soon as we make
> >>the first CS which uses them and marked as dirty when we are done
> >>with them. In between those two events the page shouldn't be written
> >>back to disk.
> >Page could be dirty prior to be pin, or dirtied after being (CPU access).
> >I am just pointing out that the GPU might be writting to the page while
> >the page is use as source for disk I/O.
> 
> I still don't see the problem here, the worst thing that could
> happen is that we write a halve filled page to disk. But since we
> set the dirty bit again after the GPU is done with the pages it
> should be written back to disk again if necessary.

This break the fsync semantic and expectation. This is the reason why the
cpu mapping is set to read only while disk i/o is in progress.

> 
> [SNIP]
> >The biggest issue with it is the pining of memory, this violate the memcg.
> >Direct-io pin memory but limit itself to a reasonable amount at a time.
> >A GPU buffer object might be several hundred mega byte which obviously
> >can be nasty from memory starvation point of view.
> 
> I thought we would handle this gracefully by accounting the memory
> pinned down to the GTT size as well. E.g. allocating GTT buffers
> pins down memory in the same way we would pin it down through this
> interface.
> 
> In the end the maximum amount of pinned down memory is always the GTT size.

Yes this could be argued that way, that anyway user than can use the gpu
can already pin large amount of ram. But pining anonymous memory or file
backed memory (ie non regular bo memory) is different as pages are still
on the lru list and thus the vmscan code will still go over them which
might worsen the out of memory case.

> 
> Regards,
> Christian.
> 
> >
> >Most other issue can be worked out.
> >
> >Cheers,
> >J?r?me
> >
> 

[RFC] drm/msm: DT support for 8960/8064

[Rob Clark]

Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
add necessary DT support so that we can use drm/msm on upstream kernel.

Signed-off-by: Rob Clark 
---
Commence bikeshedding :-)

 Documentation/devicetree/bindings/drm/msm/gpu.txt  | 51 
 Documentation/devicetree/bindings/drm/msm/hdmi.txt | 43 +
 Documentation/devicetree/bindings/drm/msm/msm.txt  | 40 
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |  2 +
 drivers/gpu/drm/msm/hdmi/hdmi.c| 55 ++
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 10 ++--
 drivers/gpu/drm/msm/msm_drv.c  | 29 ++--
 7 files changed, 204 insertions(+), 26 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/drm/msm/gpu.txt
 create mode 100644 Documentation/devicetree/bindings/drm/msm/hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/drm/msm/msm.txt

diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt 
b/Documentation/devicetree/bindings/drm/msm/gpu.txt
new file mode 100644
index 000..6e33efe
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/msm/gpu.txt
@@ -0,0 +1,51 @@
+Qualcomm adreno/snapdragon GPU
+
+Required properties:
+- compatible: "qcom,adreno-3xx"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt outputs from the controller.
+- clocks: device clocks
+  See ../clocks/clock-bindings.txt for details.
+- qcom,chipid: gpu chip-id.  Note this may become optional for future
+  devices if we can reliably read the chipid from hw
+- qcom,gpu-pwrlevels: array of OPPs, sorted highest to lowest
+  - compatible: "qcom,gpu-pwrlevels"
+  - for each qcom,gpu-pwrlevel:
+- qcom,gpu-freq: requested gpu clock speed
+- NOTE: downstream android driver defines additional parameters to
+  configure memory bandwidth scaling per OPP.
+
+Optional properties:
+- n/a
+
+Example:
+
+/ {
+   ...
+
+   gpu: qcom,kgsl-3d0 at 430 {
+   compatible = "qcom,adreno-3xx";
+   reg = <0x0430 0x2>;
+   reg-names = "kgsl_3d0_reg_memory";
+   interrupts = ;
+   interrupt-names = "kgsl_3d0_irq";
+   clock-names =
+   "core_clk",
+   "iface_clk",
+   "mem_iface_clk";
+   clocks =
+   < GFX3D_CLK>,
+   < GFX3D_AHB_CLK>,
+   < MMSS_IMEM_AHB_CLK>;
+   qcom,chipid = <0x03020100>;
+   qcom,gpu-pwrlevels {
+   compatible = "qcom,gpu-pwrlevels";
+   qcom,gpu-pwrlevel at 0 {
+   qcom,gpu-freq = <45000>;
+   };
+   qcom,gpu-pwrlevel at 1 {
+   qcom,gpu-freq = <2700>;
+   };
+   };
+   };
+};
diff --git a/Documentation/devicetree/bindings/drm/msm/hdmi.txt 
b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
new file mode 100644
index 000..051a49f
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/msm/hdmi.txt
@@ -0,0 +1,43 @@
+Qualcomm adreno/snapdragon hdmi output
+
+Required properties:
+- compatible: "qcom,hdmi-tx-8x60", "qcom,hdmi-tx-8960", "qcom,hdmi-tx-8x74"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt outputs from the controller.
+- clocks: device clocks
+  See ../clocks/clock-bindings.txt for details.
+- qcom,hdmi-tx-ddc-clk: ddc clk pin
+- qcom,hdmi-tx-ddc-data: ddc data pin
+- qcom,hdmi-tx-hpd: hpd pin
+- core-vdda-supply: phandle to supply regulator
+- hdmi-mux-supply: phandle to mux regulator
+
+Optional properties:
+- qcom,hdmi-tx-mux-en: hdmi mux enable pin
+- qcom,hdmi-tx-mux-sel: hdmi mux select pin
+
+Example:
+
+/ {
+   ...
+
+   hdmi: qcom,hdmi-tx-8960 at 4a0 {
+   compatible = "qcom,hdmi-tx-8960";
+   reg-names = "core_physical";
+   reg = <0x04a0 0x1000>;
+   interrupts = ;
+   clock-names =
+   "core_clk",
+   "master_iface_clk",
+   "slave_iface_clk";
+   clocks =
+   < HDMI_APP_CLK>,
+   < HDMI_M_AHB_CLK>,
+   < HDMI_S_AHB_CLK>;
+   qcom,hdmi-tx-ddc-clk = < 70 GPIO_ACTIVE_HIGH>;
+   qcom,hdmi-tx-ddc-data = < 71 GPIO_ACTIVE_HIGH>;
+   qcom,hdmi-tx-hpd = < 72 GPIO_ACTIVE_HIGH>;
+   core-vdda-supply = <_hdmi_mvs>;
+   hdmi-mux-supply = <_3p3v>;
+   };
+};
diff --git a/Documentation/devicetree/bindings/drm/msm/msm.txt 
b/Documentation/devicetree/bindings/drm/msm/msm.txt
new file mode 100644
index 000..484cc12
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/msm/msm.txt
@@ -0,0 +1,40 @@
+Qualcomm adreno/snapdragon
+
+Required 

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

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

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

--- Comment #21 from Sylvain BERTRAND  ---
Ok. I made a mistake. I inverted the result I debugged for can_flip! It was
returning FALSE not TRUE... my mistake and my bad.

Now, I got debug version of the ati dri stuff too. Still some weird breakpoint
behavior though. But I managed my way with what was still consistent about
breakpoint behaviour.

can_flip never returns TRUE. All the time FALSE.

Yes, awesomenauts does run full screen (1920x1200)
No compositing window manager is running (xfwm with compositing disabled).

Then we may conclude that awesomenauts is not using root pixmap flip compatible
pixmaps. I guess that would be the same issue with "life goes on".
It would mean the pixmap transformation is costing too much in time regarding
vblank time, making happen the swap in the middle of the visible screen.

dirty :(

-- 
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/20140701/65de8bc9/attachment.html>

[PATCH] drm/crtc-helper: use drm_framebuffer flags

[Fabien DESSENNE]

The "flags" parameter of the DRM_IOCTL_MODE_ADDFB2 ioctl must be
propagated and used by the driver.
The only possible value of flags is DRM_MODE_FB_INTERLACED.

Signed-off-by: Fabien Dessenne 
Reviewed-by: Benjamin GAIGNARD 
---
 drivers/gpu/drm/drm_crtc_helper.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 23500c0..5974489 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -966,6 +966,7 @@ int drm_helper_mode_fill_fb_struct(struct drm_framebuffer 
*fb,
drm_fb_get_bpp_depth(mode_cmd->pixel_format, >depth,
>bits_per_pixel);
fb->pixel_format = mode_cmd->pixel_format;
+   fb->flags = mode_cmd->flags;

return 0;
 }
-- 
1.9.1

[PATCH] drm/crtc-helper: use drm_framebuffer flags

[Fabien DESSENNE]

The "flags" parameter of the DRM_IOCTL_MODE_ADDFB2 ioctl must be
propagated and used by the driver.
The only possible value of flags is DRM_MODE_FB_INTERLACED.

Change-Id: I989c01b1e6eef753eb004a5ac876665ea8ab0da6
Signed-off-by: Fabien Dessenne 
Change-Id: I2350ad8bd1553a4a7388e8d8b7733e65f1e8caef
Reviewed-on: https://gerrit.st.com/8141
Reviewed-by: Benjamin GAIGNARD 
---
 drivers/gpu/drm/drm_crtc_helper.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 23500c0..5974489 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -966,6 +966,7 @@ int drm_helper_mode_fill_fb_struct(struct drm_framebuffer 
*fb,
drm_fb_get_bpp_depth(mode_cmd->pixel_format, >depth,
>bits_per_pixel);
fb->pixel_format = mode_cmd->pixel_format;
+   fb->flags = mode_cmd->flags;

return 0;
 }
-- 
1.9.1

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

[Christian König]

Am 01.07.2014 08:48, schrieb Michel D?nzer:
> On 30.06.2014 16:43, Christian K?nig wrote:
>> Am 30.06.2014 08:10, schrieb Michel D?nzer:
>>> On 29.06.2014 19:34, Christian K?nig wrote:
 I've just pushed the branch testing-3.15 to
 git://people.freedesktop.org/~deathsimple/linux. It's based on 3.15.2
 and contains the "stop poisoning the GART TLB" patch backported to 3.15
 and a couple of things that I would like to try.
>>> Running that branch, my Bonaire just survived a piglit run without
>>> lockup. I hope that's an interesting result. :)
>> That's indeed an interesting result. Can you try to figure out which of
>> the patches on the branch did the trick for you?
> The winner is 'drm/radeon: completely over allocate PD and PTs'. That
> patch alone on top of 3.15.2 makes piglit survive on my Bonaire.

Sounds like we either need to align the buffers a bit more, accidentally 
overwrite parts of them or indeed messed up their size calculation 
somewhere.

I've just pushed a new branch testing-3.15-v2 to 
git://people.freedesktop.org/~deathsimple/linux. It only contains the 
two patches already submitted for 3.15 inclusion and the "drm/radeon: 
completely over allocate PD and PTs" patch split into four separate changes.

Please retest and if it still works try once more which change fixed it. 
I'm going to try to purposely un-align the buffers on my bonaire in the 
meantime, maybe I get it to crash as well.

Thanks,
Christian.

[Bug 79696] 10.2.x GPU stall & Xorg crash while using Geeqie

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

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

Marti Raudsepp  changed:

   What|Removed |Added

Summary|10.2.0rc5 GPU stall & Xorg  |10.2.x GPU stall & Xorg
   |crash while using Geeqie|crash while using Geeqie

--- Comment #15 from Marti Raudsepp  ---
(In reply to comment #12)
> FYI I see a similar GPU stalls/display blanks with an upgrade from 10.1.4 ->
> 10.2.1. I am on Verde with VERDE_mc2.bin.

What's the workload that causes this issue for you? Perhaps, if it's the same
bug, running Geeqie slideshow can reproduce it faster.

-- 
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/20140701/4f4baa45/attachment.html>

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

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

--- Comment #29 from Alex Deucher  ---
(In reply to comment #28)
> Was the patch pushed upstream yet? If so how would I know, because I'd like
> to upgrade to kernel 3.14 or 3.15 for better performance with my APU.

Not yet.  It'll be in my -fixes pull request this week.

-- 
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/20140701/fa78b08c/attachment-0001.html>

[PATCH v2 1/9] dma-buf: move to drivers/dma-buf

[Maarten Lankhorst]

op 01-07-14 13:06, Arend van Spriel schreef:
> On 01-07-14 12:57, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst 
> It would help to use '-M' option with format-patch for this kind of rework.
>
> Regards,
> Arend
>
Thanks, was looking for some option but didn't find it.

Have a rediff below. :-)
8< 

Signed-off-by: Maarten Lankhorst 
---
 Documentation/DocBook/device-drivers.tmpl | 3 +--
 MAINTAINERS   | 4 ++--
 drivers/Makefile  | 1 +
 drivers/base/Makefile | 1 -
 drivers/dma-buf/Makefile  | 1 +
 drivers/{base => dma-buf}/dma-buf.c   | 0
 drivers/{base => dma-buf}/reservation.c   | 0
 7 files changed, 5 insertions(+), 5 deletions(-)
 create mode 100644 drivers/dma-buf/Makefile
 rename drivers/{base => dma-buf}/dma-buf.c (100%)
 rename drivers/{base => dma-buf}/reservation.c (100%)

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index cc63f30de166..ac61ebd92875 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,8 +128,7 @@ X!Edrivers/base/interface.c
 !Edrivers/base/bus.c
  
  Device Drivers DMA Management
-!Edrivers/base/dma-buf.c
-!Edrivers/base/reservation.c
+!Edrivers/dma-buf/dma-buf.c
 !Iinclude/linux/reservation.h
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 134483f206e4..c948e53a4ee6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2882,8 +2882,8 @@ S:Maintained
 L: linux-media at vger.kernel.org
 L: dri-devel at lists.freedesktop.org
 L: linaro-mm-sig at lists.linaro.org
-F: drivers/base/dma-buf*
-F: include/linux/dma-buf*
+F: drivers/dma-buf/
+F: include/linux/dma-buf* include/linux/reservation.h
 F: Documentation/dma-buf-sharing.txt
 T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

diff --git a/drivers/Makefile b/drivers/Makefile
index f98b50d8251d..c00337be5351 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_FB_INTEL)  += video/fbdev/intelfb/

 obj-$(CONFIG_PARPORT)  += parport/
 obj-y  += base/ block/ misc/ mfd/ nfc/
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
 obj-$(CONFIG_NUBUS)+= nubus/
 obj-y  += macintosh/
 obj-$(CONFIG_IDE)  += ide/
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e0fa51..4aab26ec0292 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o reservation.o
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
new file mode 100644
index ..4a4f4c9bacd0
--- /dev/null
+++ b/drivers/dma-buf/Makefile
@@ -0,0 +1 @@
+obj-y := dma-buf.o reservation.o
diff --git a/drivers/base/dma-buf.c b/drivers/dma-buf/dma-buf.c
similarity index 100%
rename from drivers/base/dma-buf.c
rename to drivers/dma-buf/dma-buf.c
diff --git a/drivers/base/reservation.c b/drivers/dma-buf/reservation.c
similarity index 100%
rename from drivers/base/reservation.c
rename to drivers/dma-buf/reservation.c
-- 
2.0.0

[PATCH v2 1/9] dma-buf: move to drivers/dma-buf

[Arend van Spriel]

On 01-07-14 12:57, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst 

It would help to use '-M' option with format-patch for this kind of rework.

Regards,
Arend

> ---
>  Documentation/DocBook/device-drivers.tmpl |3 
>  MAINTAINERS   |4 
>  drivers/Makefile  |1 
>  drivers/base/Makefile |1 
>  drivers/base/dma-buf.c|  743 
> -
>  drivers/base/reservation.c|   39 --
>  drivers/dma-buf/Makefile  |1 
>  drivers/dma-buf/dma-buf.c |  743 
> +
>  drivers/dma-buf/reservation.c |   39 ++
>  9 files changed, 787 insertions(+), 787 deletions(-)
>  delete mode 100644 drivers/base/dma-buf.c
>  delete mode 100644 drivers/base/reservation.c
>  create mode 100644 drivers/dma-buf/Makefile
>  create mode 100644 drivers/dma-buf/dma-buf.c
>  create mode 100644 drivers/dma-buf/reservation.c
> 
> diff --git a/Documentation/DocBook/device-drivers.tmpl 
> b/Documentation/DocBook/device-drivers.tmpl
> index cc63f30de166..ac61ebd92875 100644
> --- a/Documentation/DocBook/device-drivers.tmpl
> +++ b/Documentation/DocBook/device-drivers.tmpl
> @@ -128,8 +128,7 @@ X!Edrivers/base/interface.c
>  !Edrivers/base/bus.c
>   
>   Device Drivers DMA Management
> -!Edrivers/base/dma-buf.c
> -!Edrivers/base/reservation.c
> +!Edrivers/dma-buf/dma-buf.c
>  !Iinclude/linux/reservation.h
>  !Edrivers/base/dma-coherent.c
>  !Edrivers/base/dma-mapping.c
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 134483f206e4..c948e53a4ee6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2882,8 +2882,8 @@ S:  Maintained
>  L:   linux-media at vger.kernel.org
>  L:   dri-devel at lists.freedesktop.org
>  L:   linaro-mm-sig at lists.linaro.org
> -F:   drivers/base/dma-buf*
> -F:   include/linux/dma-buf*
> +F:   drivers/dma-buf/
> +F:   include/linux/dma-buf* include/linux/reservation.h
>  F:   Documentation/dma-buf-sharing.txt
>  T:   git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
>  
> diff --git a/drivers/Makefile b/drivers/Makefile
> index f98b50d8251d..c00337be5351 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_FB_INTEL)  += video/fbdev/intelfb/
>  
>  obj-$(CONFIG_PARPORT)+= parport/
>  obj-y+= base/ block/ misc/ mfd/ nfc/
> +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
>  obj-$(CONFIG_NUBUS)  += nubus/
>  obj-y+= macintosh/
>  obj-$(CONFIG_IDE)+= ide/
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 04b314e0fa51..4aab26ec0292 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -10,7 +10,6 @@ obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
>  obj-y+= power/
>  obj-$(CONFIG_HAS_DMA)+= dma-mapping.o
>  obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
> -obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o reservation.o
>  obj-$(CONFIG_ISA)+= isa.o
>  obj-$(CONFIG_FW_LOADER)  += firmware_class.o
>  obj-$(CONFIG_NUMA)   += node.o
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> deleted file mode 100644
> index 840c7fa80983..
> --- a/drivers/base/dma-buf.c
> +++ /dev/null
> @@ -1,743 +0,0 @@
> -/*
> - * Framework for buffer objects that can be shared across devices/subsystems.
> - *
> - * Copyright(C) 2011 Linaro Limited. All rights reserved.
> - * Author: Sumit Semwal 
> - *
> - * Many thanks to linaro-mm-sig list, and specially
> - * Arnd Bergmann , Rob Clark  and
> - * Daniel Vetter  for their support in creation and
> - * refining of this idea.
> - *
> - * 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.
> - *
> - * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program.  If not, see .
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -static inline int is_dma_buf_file(struct file *);
> -
> -struct dma_buf_list {
> - struct list_head head;
> - struct mutex lock;
> -};
> -
> -static struct dma_buf_list db_list;
> -
> -static int dma_buf_release(struct inode *inode, struct file *file)
> -{
> - struct dma_buf *dmabuf;
> -
> - if (!is_dma_buf_file(file))
> - return -EINVAL;
> -
> - dmabuf = file->private_data;
> -
> - BUG_ON(dmabuf->vmapping_counter);
> -
> - 

[PATCH v2 9/9] reservation: add suppport for read-only access using rcu

[Maarten Lankhorst]

This adds some extra functions to deal with rcu.

reservation_object_get_fences_rcu() will obtain the list of shared
and exclusive fences without obtaining the ww_mutex.

reservation_object_wait_timeout_rcu() will wait on all fences of the
reservation_object, without obtaining the ww_mutex.

reservation_object_test_signaled_rcu() will test if all fences of the
reservation_object are signaled without using the ww_mutex.

reservation_object_get_excl and reservation_object_get_list require
the reservation object to be held, updating requires
write_seqcount_begin/end. If only the exclusive fence is needed,
rcu_dereference followed by fence_get_rcu can be used, if the shared
fences are needed it's recommended to use the supplied functions.

Signed-off-by: Maarten Lankhorst 
Reviewed-By: Thomas Hellstrom 
---
 drivers/dma-buf/dma-buf.c |   47 --
 drivers/dma-buf/fence.c   |2 
 drivers/dma-buf/reservation.c |  336 ++---
 include/linux/fence.h |   17 ++
 include/linux/reservation.h   |   52 --
 5 files changed, 400 insertions(+), 54 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index cb8379dfeed5..f3014c448e1e 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -137,7 +137,7 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
struct reservation_object_list *fobj;
struct fence *fence_excl;
unsigned long events;
-   unsigned shared_count;
+   unsigned shared_count, seq;

dmabuf = file->private_data;
if (!dmabuf || !dmabuf->resv)
@@ -151,14 +151,20 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
if (!events)
return 0;

-   ww_mutex_lock(>lock, NULL);
+retry:
+   seq = read_seqcount_begin(>seq);
+   rcu_read_lock();

-   fobj = resv->fence;
-   if (!fobj)
-   goto out;
-
-   shared_count = fobj->shared_count;
-   fence_excl = resv->fence_excl;
+   fobj = rcu_dereference(resv->fence);
+   if (fobj)
+   shared_count = fobj->shared_count;
+   else
+   shared_count = 0;
+   fence_excl = rcu_dereference(resv->fence_excl);
+   if (read_seqcount_retry(>seq, seq)) {
+   rcu_read_unlock();
+   goto retry;
+   }

if (fence_excl && (!(events & POLLOUT) || shared_count == 0)) {
struct dma_buf_poll_cb_t *dcb = >cb_excl;
@@ -176,14 +182,20 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
spin_unlock_irq(>poll.lock);

if (events & pevents) {
-   if (!fence_add_callback(fence_excl, >cb,
+   if (!fence_get_rcu(fence_excl)) {
+   /* force a recheck */
+   events &= ~pevents;
+   dma_buf_poll_cb(NULL, >cb);
+   } else if (!fence_add_callback(fence_excl, >cb,
   dma_buf_poll_cb)) {
events &= ~pevents;
+   fence_put(fence_excl);
} else {
/*
 * No callback queued, wake up any additional
 * waiters.
 */
+   fence_put(fence_excl);
dma_buf_poll_cb(NULL, >cb);
}
}
@@ -205,13 +217,26 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
goto out;

for (i = 0; i < shared_count; ++i) {
-   struct fence *fence = fobj->shared[i];
+   struct fence *fence = rcu_dereference(fobj->shared[i]);

+   if (!fence_get_rcu(fence)) {
+   /*
+* fence refcount dropped to zero, this means
+* that fobj has been freed
+*
+* call dma_buf_poll_cb and force a recheck!
+*/
+   events &= ~POLLOUT;
+   dma_buf_poll_cb(NULL, >cb);
+   break;
+   }
if (!fence_add_callback(fence, >cb,
dma_buf_poll_cb)) {
+   fence_put(fence);
events &= ~POLLOUT;
break;
}
+   fence_put(fence);
}

/* No callback queued, wake up any additional waiters. */
@@ -220,7 +245,7 @@ static unsigned int dma_buf_poll(struct file *file, 

[PATCH v2 8/9] reservation: update api and add some helpers

[Maarten Lankhorst]

Move the list of shared fences to a struct, and return it in
reservation_object_get_list().
Add reservation_object_get_excl to get the exclusive fence.

Add reservation_object_reserve_shared(), which reserves space
in the reservation_object for 1 more shared fence.

reservation_object_add_shared_fence() and
reservation_object_add_excl_fence() are used to assign a new
fence to a reservation_object pointer, to complete a reservation.

Signed-off-by: Maarten Lankhorst 

Changes since v1:
- Add reservation_object_get_excl, reorder code a bit.
---
 Documentation/DocBook/device-drivers.tmpl |1 
 drivers/dma-buf/dma-buf.c |   35 ---
 drivers/dma-buf/reservation.c |  156 +
 include/linux/reservation.h   |   56 +-
 4 files changed, 229 insertions(+), 19 deletions(-)

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index ed0ef00cd7bc..dd3f278faa8a 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -133,6 +133,7 @@ X!Edrivers/base/interface.c
 !Edrivers/dma-buf/seqno-fence.c
 !Iinclude/linux/fence.h
 !Iinclude/linux/seqno-fence.h
+!Edrivers/dma-buf/reservation.c
 !Iinclude/linux/reservation.h
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 25e8c4165936..cb8379dfeed5 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -134,7 +134,10 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
 {
struct dma_buf *dmabuf;
struct reservation_object *resv;
+   struct reservation_object_list *fobj;
+   struct fence *fence_excl;
unsigned long events;
+   unsigned shared_count;

dmabuf = file->private_data;
if (!dmabuf || !dmabuf->resv)
@@ -150,12 +153,18 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)

ww_mutex_lock(>lock, NULL);

-   if (resv->fence_excl && (!(events & POLLOUT) ||
-resv->fence_shared_count == 0)) {
+   fobj = resv->fence;
+   if (!fobj)
+   goto out;
+
+   shared_count = fobj->shared_count;
+   fence_excl = resv->fence_excl;
+
+   if (fence_excl && (!(events & POLLOUT) || shared_count == 0)) {
struct dma_buf_poll_cb_t *dcb = >cb_excl;
unsigned long pevents = POLLIN;

-   if (resv->fence_shared_count == 0)
+   if (shared_count == 0)
pevents |= POLLOUT;

spin_lock_irq(>poll.lock);
@@ -167,19 +176,20 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
spin_unlock_irq(>poll.lock);

if (events & pevents) {
-   if (!fence_add_callback(resv->fence_excl,
-   >cb, dma_buf_poll_cb))
+   if (!fence_add_callback(fence_excl, >cb,
+  dma_buf_poll_cb)) {
events &= ~pevents;
-   else
+   } else {
/*
 * No callback queued, wake up any additional
 * waiters.
 */
dma_buf_poll_cb(NULL, >cb);
+   }
}
}

-   if ((events & POLLOUT) && resv->fence_shared_count > 0) {
+   if ((events & POLLOUT) && shared_count > 0) {
struct dma_buf_poll_cb_t *dcb = >cb_shared;
int i;

@@ -194,15 +204,18 @@ static unsigned int dma_buf_poll(struct file *file, 
poll_table *poll)
if (!(events & POLLOUT))
goto out;

-   for (i = 0; i < resv->fence_shared_count; ++i)
-   if (!fence_add_callback(resv->fence_shared[i],
-   >cb, dma_buf_poll_cb)) {
+   for (i = 0; i < shared_count; ++i) {
+   struct fence *fence = fobj->shared[i];
+
+   if (!fence_add_callback(fence, >cb,
+   dma_buf_poll_cb)) {
events &= ~POLLOUT;
break;
}
+   }

/* No callback queued, wake up any additional waiters. */
-   if (i == resv->fence_shared_count)
+   if (i == shared_count)
dma_buf_poll_cb(NULL, >cb);
}

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index a73fbf3b8e56..e6166723a9ae 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2012-2013 Canonical Ltd
+ * 

[PATCH v2 7/9] dma-buf: add poll support, v3

[Maarten Lankhorst]

Thanks to Fengguang Wu for spotting a missing static cast.

v2:
- Kill unused variable need_shared.
v3:
- Clarify the BUG() in dma_buf_release some more. (Rob Clark)

Signed-off-by: Maarten Lankhorst 
---
 drivers/dma-buf/dma-buf.c |  108 +
 include/linux/dma-buf.h   |   12 +
 2 files changed, 120 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index cd40ca22911f..25e8c4165936 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 static inline int is_dma_buf_file(struct file *);
@@ -52,6 +53,16 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)

BUG_ON(dmabuf->vmapping_counter);

+   /*
+* Any fences that a dma-buf poll can wait on should be signaled
+* before releasing dma-buf. This is the responsibility of each
+* driver that uses the reservation objects.
+*
+* If you hit this BUG() it means someone dropped their ref to the
+* dma-buf while still having pending operation to the buffer.
+*/
+   BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
+
dmabuf->ops->release(dmabuf);

mutex_lock(_list.lock);
@@ -108,10 +119,103 @@ static loff_t dma_buf_llseek(struct file *file, loff_t 
offset, int whence)
return base + offset;
 }

+static void dma_buf_poll_cb(struct fence *fence, struct fence_cb *cb)
+{
+   struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t *)cb;
+   unsigned long flags;
+
+   spin_lock_irqsave(>poll->lock, flags);
+   wake_up_locked_poll(dcb->poll, dcb->active);
+   dcb->active = 0;
+   spin_unlock_irqrestore(>poll->lock, flags);
+}
+
+static unsigned int dma_buf_poll(struct file *file, poll_table *poll)
+{
+   struct dma_buf *dmabuf;
+   struct reservation_object *resv;
+   unsigned long events;
+
+   dmabuf = file->private_data;
+   if (!dmabuf || !dmabuf->resv)
+   return POLLERR;
+
+   resv = dmabuf->resv;
+
+   poll_wait(file, >poll, poll);
+
+   events = poll_requested_events(poll) & (POLLIN | POLLOUT);
+   if (!events)
+   return 0;
+
+   ww_mutex_lock(>lock, NULL);
+
+   if (resv->fence_excl && (!(events & POLLOUT) ||
+resv->fence_shared_count == 0)) {
+   struct dma_buf_poll_cb_t *dcb = >cb_excl;
+   unsigned long pevents = POLLIN;
+
+   if (resv->fence_shared_count == 0)
+   pevents |= POLLOUT;
+
+   spin_lock_irq(>poll.lock);
+   if (dcb->active) {
+   dcb->active |= pevents;
+   events &= ~pevents;
+   } else
+   dcb->active = pevents;
+   spin_unlock_irq(>poll.lock);
+
+   if (events & pevents) {
+   if (!fence_add_callback(resv->fence_excl,
+   >cb, dma_buf_poll_cb))
+   events &= ~pevents;
+   else
+   /*
+* No callback queued, wake up any additional
+* waiters.
+*/
+   dma_buf_poll_cb(NULL, >cb);
+   }
+   }
+
+   if ((events & POLLOUT) && resv->fence_shared_count > 0) {
+   struct dma_buf_poll_cb_t *dcb = >cb_shared;
+   int i;
+
+   /* Only queue a new callback if no event has fired yet */
+   spin_lock_irq(>poll.lock);
+   if (dcb->active)
+   events &= ~POLLOUT;
+   else
+   dcb->active = POLLOUT;
+   spin_unlock_irq(>poll.lock);
+
+   if (!(events & POLLOUT))
+   goto out;
+
+   for (i = 0; i < resv->fence_shared_count; ++i)
+   if (!fence_add_callback(resv->fence_shared[i],
+   >cb, dma_buf_poll_cb)) {
+   events &= ~POLLOUT;
+   break;
+   }
+
+   /* No callback queued, wake up any additional waiters. */
+   if (i == resv->fence_shared_count)
+   dma_buf_poll_cb(NULL, >cb);
+   }
+
+out:
+   ww_mutex_unlock(>lock);
+   return events;
+}
+
 static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
+   .poll   = dma_buf_poll,
 };

 /*
@@ -171,6 +275,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;

[PATCH v2 6/9] reservation: add support for fences to enable cross-device synchronisation

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Rob Clark 
---
 include/linux/reservation.h |   20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..f3f57460a205 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -6,7 +6,7 @@
  * Copyright (C) 2012 Texas Instruments
  *
  * Authors:
- * Rob Clark 
+ * Rob Clark 
  * Maarten Lankhorst 
  * Thomas Hellstrom 
  *
@@ -40,22 +40,40 @@
 #define _LINUX_RESERVATION_H

 #include 
+#include 
+#include 

 extern struct ww_class reservation_ww_class;

 struct reservation_object {
struct ww_mutex lock;
+
+   struct fence *fence_excl;
+   struct fence **fence_shared;
+   u32 fence_shared_count, fence_shared_max;
 };

 static inline void
 reservation_object_init(struct reservation_object *obj)
 {
ww_mutex_init(>lock, _ww_class);
+
+   obj->fence_shared_count = obj->fence_shared_max = 0;
+   obj->fence_shared = NULL;
+   obj->fence_excl = NULL;
 }

 static inline void
 reservation_object_fini(struct reservation_object *obj)
 {
+   int i;
+
+   if (obj->fence_excl)
+   fence_put(obj->fence_excl);
+   for (i = 0; i < obj->fence_shared_count; ++i)
+   fence_put(obj->fence_shared[i]);
+   kfree(obj->fence_shared);
+
ww_mutex_destroy(>lock);
 }

[PATCH v2 5/9] android: convert sync to fence api, v6

[Maarten Lankhorst]

Just to show it's easy.

Android syncpoints can be mapped to a timeline. This removes the need
to maintain a separate api for synchronization. I've left the android
trace events in place, but the core fence events should already be
sufficient for debugging.

v2:
- Call fence_remove_callback in sync_fence_free if not all fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.
v4:
- Merge with the upstream fixes.
v5:
- Fix small style issues pointed out by Thomas Hellstrom.
v6:
- Fix for updates to fence api.

Signed-off-by: Maarten Lankhorst 
Acked-by: John Stultz 
---
 drivers/staging/android/Kconfig  |1 
 drivers/staging/android/Makefile |2 
 drivers/staging/android/sw_sync.c|6 
 drivers/staging/android/sync.c   |  913 +++---
 drivers/staging/android/sync.h   |   79 ++-
 drivers/staging/android/sync_debug.c |  247 +
 drivers/staging/android/trace/sync.h |   12 
 7 files changed, 609 insertions(+), 651 deletions(-)
 create mode 100644 drivers/staging/android/sync_debug.c

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 99e484f845f2..51607e9aa049 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -88,6 +88,7 @@ config SYNC
bool "Synchronization framework"
default n
select ANON_INODES
+   select DMA_SHARED_BUFFER
---help---
  This option enables the framework for synchronization between multiple
  drivers.  Sync implementations can take advantage of hardware
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index 0a01e1914905..517ad5ffa429 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -9,5 +9,5 @@ obj-$(CONFIG_ANDROID_TIMED_OUTPUT)  += timed_output.o
 obj-$(CONFIG_ANDROID_TIMED_GPIO)   += timed_gpio.o
 obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
 obj-$(CONFIG_ANDROID_INTF_ALARM_DEV)   += alarm-dev.o
-obj-$(CONFIG_SYNC) += sync.o
+obj-$(CONFIG_SYNC) += sync.o sync_debug.o
 obj-$(CONFIG_SW_SYNC)  += sw_sync.o
diff --git a/drivers/staging/android/sw_sync.c 
b/drivers/staging/android/sw_sync.c
index 12a136ec1cec..a76db3ff87cb 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -50,7 +50,7 @@ static struct sync_pt *sw_sync_pt_dup(struct sync_pt *sync_pt)
 {
struct sw_sync_pt *pt = (struct sw_sync_pt *) sync_pt;
struct sw_sync_timeline *obj =
-   (struct sw_sync_timeline *)sync_pt->parent;
+   (struct sw_sync_timeline *)sync_pt_parent(sync_pt);

return (struct sync_pt *) sw_sync_pt_create(obj, pt->value);
 }
@@ -59,7 +59,7 @@ static int sw_sync_pt_has_signaled(struct sync_pt *sync_pt)
 {
struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
struct sw_sync_timeline *obj =
-   (struct sw_sync_timeline *)sync_pt->parent;
+   (struct sw_sync_timeline *)sync_pt_parent(sync_pt);

return sw_sync_cmp(obj->value, pt->value) >= 0;
 }
@@ -97,7 +97,6 @@ static void sw_sync_pt_value_str(struct sync_pt *sync_pt,
   char *str, int size)
 {
struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
-
snprintf(str, size, "%d", pt->value);
 }

@@ -157,7 +156,6 @@ static int sw_sync_open(struct inode *inode, struct file 
*file)
 static int sw_sync_release(struct inode *inode, struct file *file)
 {
struct sw_sync_timeline *obj = file->private_data;
-
sync_timeline_destroy(>obj);
return 0;
 }
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 18174f7c871c..c9a0c2cdc81a 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -31,22 +31,13 @@
 #define CREATE_TRACE_POINTS
 #include "trace/sync.h"

-static void sync_fence_signal_pt(struct sync_pt *pt);
-static int _sync_pt_has_signaled(struct sync_pt *pt);
-static void sync_fence_free(struct kref *kref);
-static void sync_dump(void);
-
-static LIST_HEAD(sync_timeline_list_head);
-static DEFINE_SPINLOCK(sync_timeline_list_lock);
-
-static LIST_HEAD(sync_fence_list_head);
-static DEFINE_SPINLOCK(sync_fence_list_lock);
+static const struct fence_ops android_fence_ops;
+static const struct file_operations sync_fence_fops;

 struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
   int size, const char *name)
 {
struct sync_timeline *obj;
-   unsigned long flags;

if (size < sizeof(struct sync_timeline))
return NULL;
@@ -57,17 +48,14 @@ struct sync_timeline *sync_timeline_create(const struct 
sync_timeline_ops *ops,

kref_init(>kref);
obj->ops = ops;
+   obj->context = fence_context_alloc(1);
strlcpy(obj->name, name, 

[PATCH v2 4/9] dma-buf: use reservation objects

[Maarten Lankhorst]

This allows reservation objects to be used in dma-buf. it's required
for implementing polling support on the fences that belong to a dma-buf.

Signed-off-by: Maarten Lankhorst 
Acked-by: Mauro Carvalho Chehab  
#drivers/media/v4l2-core/
Acked-by: Thomas Hellstrom  #drivers/gpu/drm/ttm
Signed-off-by: Vincent Stehl?  
#drivers/gpu/drm/armada/
---
 drivers/dma-buf/dma-buf.c  |   22 --
 drivers/gpu/drm/armada/armada_gem.c|2 +-
 drivers/gpu/drm/drm_prime.c|8 +++-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |3 ++-
 drivers/gpu/drm/nouveau/nouveau_drm.c  |1 +
 drivers/gpu/drm/nouveau/nouveau_gem.h  |1 +
 drivers/gpu/drm/nouveau/nouveau_prime.c|7 +++
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |2 +-
 drivers/gpu/drm/radeon/radeon_drv.c|2 ++
 drivers/gpu/drm/radeon/radeon_prime.c  |8 
 drivers/gpu/drm/tegra/gem.c|2 +-
 drivers/gpu/drm/ttm/ttm_object.c   |2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
 drivers/staging/android/ion/ion.c  |3 ++-
 include/drm/drmP.h |3 +++
 include/linux/dma-buf.h|9 ++---
 17 files changed, 65 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 840c7fa80983..cd40ca22911f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -25,10 +25,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 

 static inline int is_dma_buf_file(struct file *);

@@ -56,6 +58,9 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
list_del(>list_node);
mutex_unlock(_list.lock);

+   if (dmabuf->resv == (struct reservation_object *)[1])
+   reservation_object_fini(dmabuf->resv);
+
kfree(dmabuf);
return 0;
 }
@@ -128,6 +133,7 @@ static inline int is_dma_buf_file(struct file *file)
  * @size:  [in]Size of the buffer
  * @flags: [in]mode flags for the file.
  * @exp_name:  [in]name of the exporting module - useful for debugging.
+ * @resv:  [in]reservation-object, NULL to allocate default one.
  *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
@@ -135,10 +141,17 @@ static inline int is_dma_buf_file(struct file *file)
  *
  */
 struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags, const char *exp_name)
+   size_t size, int flags, const char *exp_name,
+   struct reservation_object *resv)
 {
struct dma_buf *dmabuf;
struct file *file;
+   size_t alloc_size = sizeof(struct dma_buf);
+   if (!resv)
+   alloc_size += sizeof(struct reservation_object);
+   else
+   /* prevent _buf[1] == dma_buf->resv */
+   alloc_size += 1;

if (WARN_ON(!priv || !ops
  || !ops->map_dma_buf
@@ -150,7 +163,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
return ERR_PTR(-EINVAL);
}

-   dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
+   dmabuf = kzalloc(alloc_size, GFP_KERNEL);
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);

@@ -158,6 +171,11 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;
dmabuf->exp_name = exp_name;
+   if (!resv) {
+   resv = (struct reservation_object *)[1];
+   reservation_object_init(resv);
+   }
+   dmabuf->resv = resv;

file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf, flags);
if (IS_ERR(file)) {
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index bb9b642d8485..7496f55611a5 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -539,7 +539,7 @@ armada_gem_prime_export(struct drm_device *dev, struct 
drm_gem_object *obj,
int flags)
 {
return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
- O_RDWR);
+ O_RDWR, NULL);
 }

 struct drm_gem_object *
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 304ca8cacbc4..99d578bad17e 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -336,7 +336,13 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = 
 {
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 

[PATCH v2 3/9] seqno-fence: Hardware dma-buf implementation of fencing (v6)

[Maarten Lankhorst]

This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met when WAIT_GEQUAL is used,
or (dma_buf[offset] != 0) has been met when WAIT_NONZERO is set.

A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.

Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.

I extended the original patch by Rob Clark.

v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init
v5: Add condition member to allow wait for != 0.
Fix small style errors pointed out by checkpatch.
v6: Move to a separate file. Fix up api changes in fences.

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Rob Clark  #v4
---
 Documentation/DocBook/device-drivers.tmpl |2 +
 MAINTAINERS   |2 -
 drivers/dma-buf/Makefile  |2 -
 drivers/dma-buf/seqno-fence.c |   73 ++
 include/linux/seqno-fence.h   |  116 +
 5 files changed, 193 insertions(+), 2 deletions(-)
 create mode 100644 drivers/dma-buf/seqno-fence.c
 create mode 100644 include/linux/seqno-fence.h

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index e634657efb52..ed0ef00cd7bc 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -130,7 +130,9 @@ X!Edrivers/base/interface.c
  Device Drivers DMA Management
 !Edrivers/dma-buf/dma-buf.c
 !Edrivers/dma-buf/fence.c
+!Edrivers/dma-buf/seqno-fence.c
 !Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
 !Iinclude/linux/reservation.h
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ebc1ebf6f542..135929f6cf6a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2883,7 +2883,7 @@ L:linux-media at vger.kernel.org
 L: dri-devel at lists.freedesktop.org
 L: linaro-mm-sig at lists.linaro.org
 F: drivers/dma-buf/
-F: include/linux/dma-buf* include/linux/reservation.h include/linux/fence.h
+F: include/linux/dma-buf* include/linux/reservation.h 
include/linux/*fence.h
 F: Documentation/dma-buf-sharing.txt
 T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index d7825bfe630e..57a675f90cd0 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1 +1 @@
-obj-y := dma-buf.o fence.o reservation.o
+obj-y := dma-buf.o fence.o reservation.o seqno-fence.o
diff --git a/drivers/dma-buf/seqno-fence.c b/drivers/dma-buf/seqno-fence.c
new file mode 100644
index ..7d12a39a4b57
--- /dev/null
+++ b/drivers/dma-buf/seqno-fence.c
@@ -0,0 +1,73 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012-2014 Canonical Ltd
+ * Authors:
+ *   Rob Clark 
+ *   Maarten Lankhorst 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+
+static const char *seqno_fence_get_driver_name(struct fence *fence)
+{
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->get_driver_name(fence);
+}
+
+static const char *seqno_fence_get_timeline_name(struct fence *fence)
+{
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->get_timeline_name(fence);
+}
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->signaled && seqno_fence->ops->signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+   struct seqno_fence *f = to_seqno_fence(fence);
+
+   dma_buf_put(f->sync_buf);
+   if (f->ops->release)
+   f->ops->release(fence);
+   else
+   fence_free(>base);
+}
+
+static signed long 

[PATCH v2 2/9] fence: dma-buf cross-device synchronization (v18)

[Maarten Lankhorst]

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

When emitting a fence, call:
  + trace_fence_emit()

To annotate that a fence is blocking on another fence, call:
  + trace_fence_annotate_wait_on(fence, on_fence)

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = seqno_fence->sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override 

[PATCH v2 1/9] dma-buf: move to drivers/dma-buf

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 Documentation/DocBook/device-drivers.tmpl |3 
 MAINTAINERS   |4 
 drivers/Makefile  |1 
 drivers/base/Makefile |1 
 drivers/base/dma-buf.c|  743 -
 drivers/base/reservation.c|   39 --
 drivers/dma-buf/Makefile  |1 
 drivers/dma-buf/dma-buf.c |  743 +
 drivers/dma-buf/reservation.c |   39 ++
 9 files changed, 787 insertions(+), 787 deletions(-)
 delete mode 100644 drivers/base/dma-buf.c
 delete mode 100644 drivers/base/reservation.c
 create mode 100644 drivers/dma-buf/Makefile
 create mode 100644 drivers/dma-buf/dma-buf.c
 create mode 100644 drivers/dma-buf/reservation.c

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index cc63f30de166..ac61ebd92875 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -128,8 +128,7 @@ X!Edrivers/base/interface.c
 !Edrivers/base/bus.c
  
  Device Drivers DMA Management
-!Edrivers/base/dma-buf.c
-!Edrivers/base/reservation.c
+!Edrivers/dma-buf/dma-buf.c
 !Iinclude/linux/reservation.h
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 134483f206e4..c948e53a4ee6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2882,8 +2882,8 @@ S:Maintained
 L: linux-media at vger.kernel.org
 L: dri-devel at lists.freedesktop.org
 L: linaro-mm-sig at lists.linaro.org
-F: drivers/base/dma-buf*
-F: include/linux/dma-buf*
+F: drivers/dma-buf/
+F: include/linux/dma-buf* include/linux/reservation.h
 F: Documentation/dma-buf-sharing.txt
 T: git git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git

diff --git a/drivers/Makefile b/drivers/Makefile
index f98b50d8251d..c00337be5351 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_FB_INTEL)  += video/fbdev/intelfb/

 obj-$(CONFIG_PARPORT)  += parport/
 obj-y  += base/ block/ misc/ mfd/ nfc/
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf/
 obj-$(CONFIG_NUBUS)+= nubus/
 obj-y  += macintosh/
 obj-$(CONFIG_IDE)  += ide/
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e0fa51..4aab26ec0292 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,6 @@ obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o reservation.o
 obj-$(CONFIG_ISA)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
deleted file mode 100644
index 840c7fa80983..
--- a/drivers/base/dma-buf.c
+++ /dev/null
@@ -1,743 +0,0 @@
-/*
- * Framework for buffer objects that can be shared across devices/subsystems.
- *
- * Copyright(C) 2011 Linaro Limited. All rights reserved.
- * Author: Sumit Semwal 
- *
- * Many thanks to linaro-mm-sig list, and specially
- * Arnd Bergmann , Rob Clark  and
- * Daniel Vetter  for their support in creation and
- * refining of this idea.
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-static inline int is_dma_buf_file(struct file *);
-
-struct dma_buf_list {
-   struct list_head head;
-   struct mutex lock;
-};
-
-static struct dma_buf_list db_list;
-
-static int dma_buf_release(struct inode *inode, struct file *file)
-{
-   struct dma_buf *dmabuf;
-
-   if (!is_dma_buf_file(file))
-   return -EINVAL;
-
-   dmabuf = file->private_data;
-
-   BUG_ON(dmabuf->vmapping_counter);
-
-   dmabuf->ops->release(dmabuf);
-
-   mutex_lock(_list.lock);
-   list_del(>list_node);
-   mutex_unlock(_list.lock);
-
-   kfree(dmabuf);
-   return 0;
-}
-
-static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma)
-{
-   struct dma_buf *dmabuf;
-
-   if (!is_dma_buf_file(file))
-   return -EINVAL;
-
-   dmabuf = file->private_data;
-
-   /* 

[PATCH v2 0/9] Updated fence patch series

[Maarten Lankhorst]

So after some more hacking I've moved dma-buf to its own subdirectory,
drivers/dma-buf and applied the fence patches to its new place. I believe that 
the
first patch should be applied regardless, and the rest should be ready now.
:-)

Changes to the fence api:
- release_fence -> fence_release etc.
- __fence_init -> fence_init
- __fence_signal -> fence_signal_locked
- __fence_is_signaled -> fence_is_signaled_locked
- Changing BUG_ON to WARN_ON in fence_later, and return NULL if it triggers.

Android can expose fences to userspace. It's possible to make the new fence
mechanism expose the same fences to userspace by changing sync_fence_create
to take a struct fence instead of a struct sync_pt. No other change is needed,
because only the fence parts of struct sync_pt are used. But because the
userspace fences are a separate problem and I haven't really looked at it yet
I feel it should stay in staging, for now.

---

Maarten Lankhorst (9):
  dma-buf: move to drivers/dma-buf
  fence: dma-buf cross-device synchronization (v18)
  seqno-fence: Hardware dma-buf implementation of fencing (v6)
  dma-buf: use reservation objects
  android: convert sync to fence api, v6
  reservation: add support for fences to enable cross-device synchronisation
  dma-buf: add poll support, v3
  reservation: update api and add some helpers
  reservation: add suppport for read-only access using rcu


 Documentation/DocBook/device-drivers.tmpl  |8 
 MAINTAINERS|4 
 drivers/Makefile   |1 
 drivers/base/Kconfig   |9 
 drivers/base/Makefile  |1 
 drivers/base/dma-buf.c |  743 
 drivers/base/reservation.c |   39 -
 drivers/dma-buf/Makefile   |1 
 drivers/dma-buf/dma-buf.c  |  907 
 drivers/dma-buf/fence.c|  431 +++
 drivers/dma-buf/reservation.c  |  477 +
 drivers/dma-buf/seqno-fence.c  |   73 ++
 drivers/gpu/drm/armada/armada_gem.c|2 
 drivers/gpu/drm/drm_prime.c|8 
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |3 
 drivers/gpu/drm/nouveau/nouveau_drm.c  |1 
 drivers/gpu/drm/nouveau/nouveau_gem.h  |1 
 drivers/gpu/drm/nouveau/nouveau_prime.c|7 
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |2 
 drivers/gpu/drm/radeon/radeon_drv.c|2 
 drivers/gpu/drm/radeon/radeon_prime.c  |8 
 drivers/gpu/drm/tegra/gem.c|2 
 drivers/gpu/drm/ttm/ttm_object.c   |2 
 drivers/media/v4l2-core/videobuf2-dma-contig.c |2 
 drivers/staging/android/Kconfig|1 
 drivers/staging/android/Makefile   |2 
 drivers/staging/android/ion/ion.c  |3 
 drivers/staging/android/sw_sync.c  |6 
 drivers/staging/android/sync.c |  913 
 drivers/staging/android/sync.h |   79 +-
 drivers/staging/android/sync_debug.c   |  247 ++
 drivers/staging/android/trace/sync.h   |   12 
 include/drm/drmP.h |3 
 include/linux/dma-buf.h|   21 -
 include/linux/fence.h  |  360 +
 include/linux/reservation.h|   82 ++
 include/linux/seqno-fence.h|  116 +++
 include/trace/events/fence.h   |  128 +++
 39 files changed, 3258 insertions(+), 1451 deletions(-)
 delete mode 100644 drivers/base/dma-buf.c
 delete mode 100644 drivers/base/reservation.c
 create mode 100644 drivers/dma-buf/Makefile
 create mode 100644 drivers/dma-buf/dma-buf.c
 create mode 100644 drivers/dma-buf/fence.c
 create mode 100644 drivers/dma-buf/reservation.c
 create mode 100644 drivers/dma-buf/seqno-fence.c
 create mode 100644 drivers/staging/android/sync_debug.c
 create mode 100644 include/linux/fence.h
 create mode 100644 include/linux/seqno-fence.h
 create mode 100644 include/trace/events/fence.h

-- 
Signature

[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie

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

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

--- Comment #14 from Clemens Fruhwirth  ---
(In reply to comment #13)

> Kernel 3.15 is indeed unstable on Cape Verde. We know where the problem is.
> If kernel 3.14 doesn't hang the GPU for you, it's the same problem.

That doesn't correlate well with my testing:

3.14.x + 10.1.4 = stable
3.15.x + 10.1.4 = stable
3.14.x + 10.2.1 = unstable
3.15.x + 10.2.1 = unstable

I assume that it's something different :/

-- 
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/20140701/91ea7d61/attachment.html>

[PATCH v2] drm/radeon: Track the status of a page flip more explicitly

[Alex Deucher]

On Mon, Jun 30, 2014 at 5:12 AM, Michel D?nzer  wrote:
> From: Michel D?nzer 
>
> This prevents a panic: radeon_crtc_handle_page_flip() could run before
> radeon_flip_work_func(), triggering the BUG_ON() in drm_vblank_put().
>
> Tested-by: Dieter N?tzel 
> Signed-off-by: Michel D?nzer 
> ---
>
> v2: Update log message

Applied to to by -fixes tree.

Alex

>
>  drivers/gpu/drm/radeon/radeon_display.c | 19 ++-
>  drivers/gpu/drm/radeon/radeon_mode.h|  7 +++
>  2 files changed, 21 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 8b575a4..65882cd 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -284,7 +284,6 @@ static void radeon_unpin_work_func(struct work_struct 
> *__work)
>  void radeon_crtc_handle_vblank(struct radeon_device *rdev, int crtc_id)
>  {
> struct radeon_crtc *radeon_crtc = rdev->mode_info.crtcs[crtc_id];
> -   struct radeon_flip_work *work;
> unsigned long flags;
> u32 update_pending;
> int vpos, hpos;
> @@ -294,8 +293,11 @@ void radeon_crtc_handle_vblank(struct radeon_device 
> *rdev, int crtc_id)
> return;
>
> spin_lock_irqsave(>ddev->event_lock, flags);
> -   work = radeon_crtc->flip_work;
> -   if (work == NULL) {
> +   if (radeon_crtc->flip_status != RADEON_FLIP_SUBMITTED) {
> +   DRM_DEBUG_DRIVER("radeon_crtc->flip_status = %d != "
> +"RADEON_FLIP_SUBMITTED(%d)\n",
> +radeon_crtc->flip_status,
> +RADEON_FLIP_SUBMITTED);
> spin_unlock_irqrestore(>ddev->event_lock, flags);
> return;
> }
> @@ -343,12 +345,17 @@ void radeon_crtc_handle_flip(struct radeon_device 
> *rdev, int crtc_id)
>
> spin_lock_irqsave(>ddev->event_lock, flags);
> work = radeon_crtc->flip_work;
> -   if (work == NULL) {
> +   if (radeon_crtc->flip_status != RADEON_FLIP_SUBMITTED) {
> +   DRM_DEBUG_DRIVER("radeon_crtc->flip_status = %d != "
> +"RADEON_FLIP_SUBMITTED(%d)\n",
> +radeon_crtc->flip_status,
> +RADEON_FLIP_SUBMITTED);
> spin_unlock_irqrestore(>ddev->event_lock, flags);
> return;
> }
>
> /* Pageflip completed. Clean up. */
> +   radeon_crtc->flip_status = RADEON_FLIP_NONE;
> radeon_crtc->flip_work = NULL;
>
> /* wakeup userspace */
> @@ -475,6 +482,7 @@ static void radeon_flip_work_func(struct work_struct 
> *__work)
> /* do the flip (mmio) */
> radeon_page_flip(rdev, radeon_crtc->crtc_id, base);
>
> +   radeon_crtc->flip_status = RADEON_FLIP_SUBMITTED;
> spin_unlock_irqrestore(>dev->event_lock, flags);
> up_read(>exclusive_lock);
>
> @@ -543,7 +551,7 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
> /* We borrow the event spin lock for protecting flip_work */
> spin_lock_irqsave(>dev->event_lock, flags);
>
> -   if (radeon_crtc->flip_work) {
> +   if (radeon_crtc->flip_status != RADEON_FLIP_NONE) {
> DRM_DEBUG_DRIVER("flip queue: crtc already busy\n");
> spin_unlock_irqrestore(>dev->event_lock, flags);
> drm_gem_object_unreference_unlocked(>old_rbo->gem_base);
> @@ -551,6 +559,7 @@ static int radeon_crtc_page_flip(struct drm_crtc *crtc,
> kfree(work);
> return -EBUSY;
> }
> +   radeon_crtc->flip_status = RADEON_FLIP_PENDING;
> radeon_crtc->flip_work = work;
>
> /* update crtc fb */
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index b59096f..ed6b6e0 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -301,6 +301,12 @@ struct radeon_atom_ss {
> uint16_t amount;
>  };
>
> +enum radeon_flip_status {
> +   RADEON_FLIP_NONE,
> +   RADEON_FLIP_PENDING,
> +   RADEON_FLIP_SUBMITTED
> +};
> +
>  struct radeon_crtc {
> struct drm_crtc base;
> int crtc_id;
> @@ -326,6 +332,7 @@ struct radeon_crtc {
> /* page flipping */
> struct workqueue_struct *flip_queue;
> struct radeon_flip_work *flip_work;
> +   enum radeon_flip_status flip_status;
> /* pll sharing */
> struct radeon_atom_ss ss;
> bool ss_enabled;
> --
> 2.0.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm: i915: "plane B assertion failure, should be off on pipe B but is still active"

[Jani Nikula]

On Mon, 30 Jun 2014, Paul Bolle  wrote:
> Kernels v3.16-rc2 and v3.16-rc3 trigger a new (for me) warning. (I never
> booted v3.16-rc1). Machine is a, rather outdated, ThinkPad X41 (ie,
> single core i686).
>
> WARNING: CPU: 0 PID: 221 at drivers/gpu/drm/i915/intel_display.c:1274 
> assert_planes_disabled+0xf9/0x100 [i915]()
> plane B assertion failure, should be off on pipe B but is still active
> Modules linked in: tg3 i915(+) i2c_algo_bit drm_kms_helper ptp drm 
> ata_generic pata_acpi yenta_socket i2c_core pps_core video
> CPU: 0 PID: 221 Comm: systemd-udevd Not tainted 
> 3.16.0-0.rc3.1.local0.fc20.i686 #1
> Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET64WW (2.09 ) 12/14/2006
>  c0c87907 add7c490  f652b9ac c09fdab7 f652b9ec f652b9dc c045008e
>  f830c6cc f652ba0c 00dd f830c634 04fa f82b4d59 f82b4d59 f6728000
>  0001 f65a8c00 f652b9f8 c04500ee 0009 f652b9ec f830c6cc f652ba0c
> Call Trace:
>  [] dump_stack+0x41/0x52
>  [] warn_slowpath_common+0x7e/0xa0
>  [] ? assert_planes_disabled+0xf9/0x100 [i915]
>  [] ? assert_planes_disabled+0xf9/0x100 [i915]
>  [] warn_slowpath_fmt+0x3e/0x60
>  [] assert_planes_disabled+0xf9/0x100 [i915]
>  [] intel_disable_pipe+0x26/0xb0 [i915]
>  [] ? gen4_read8+0xc0/0xc0 [i915]
>  [] i9xx_crtc_disable+0x93/0x3d0 [i915]
>  [] intel_modeset_setup_hw_state+0x7ac/0xbc0 [i915]
>  [] ? gen4_read8+0xc0/0xc0 [i915]
>  [] ? drm_modeset_lock_all_crtcs+0x3c/0x50 [drm]
>  [] intel_modeset_init+0x734/0x1220 [i915]
>  [] ? i915_enable_pipestat+0xab/0x120 [i915]
>  [] ? i915_irq_postinstall+0x104/0x110 [i915]
>  [] ? drm_irq_install+0xa9/0x170 [drm]
>  [] i915_driver_load+0xa76/0xe70 [i915]
>  [] ? i915_switcheroo_set_state+0x90/0x90 [i915]
>  [] ? cleanup_uevent_env+0x10/0x10
>  [] ? sysfs_add_file+0x23/0x30
>  [] ? get_device+0x14/0x30
>  [] ? klist_class_dev_get+0x12/0x20
>  [] ? klist_node_init+0x2e/0x50
>  [] ? klist_add_tail+0x27/0x30
>  [] ? device_add+0x1d6/0x5a0
>  [] ? drm_sysfs_device_add+0xba/0x100 [drm]
>  [] drm_dev_register+0x8e/0xe0 [drm]
>  [] drm_get_pci_dev+0x79/0x1c0 [drm]
>  [] i915_pci_probe+0x35/0x60 [i915]
>  [] pci_device_probe+0x6f/0xc0
>  [] ? sysfs_create_link+0x25/0x40
>  [] driver_probe_device+0x93/0x3a0
>  [] ? sysfs_create_dir_ns+0x37/0x80
>  [] ? pci_match_device+0xc1/0xe0
>  [] __driver_attach+0x71/0x80
>  [] ? __device_attach+0x40/0x40
>  [] bus_for_each_dev+0x57/0xa0
>  [] driver_attach+0x1e/0x20
>  [] ? __device_attach+0x40/0x40
>  [] bus_add_driver+0x157/0x230
>  [] ? 0xf7fc7fff
>  [] ? 0xf7fc7fff
>  [] driver_register+0x59/0xe0
>  [] ? __kmalloc_track_caller+0x46/0x1f0
>  [] __pci_register_driver+0x32/0x40
>  [] drm_pci_init+0xe5/0x110 [drm]
>  [] ? 0xf7fc7fff
>  [] i915_init+0x88/0x8a [i915]
>  [] ? 0xf7fc7fff
>  [] do_one_initcall+0xc2/0x1f0
>  [] ? 0xf7fc7fff
>  [] ? kfree+0xdd/0x120
>  [] ? __vunmap+0x8f/0xe0
>  [] ? __vunmap+0x8f/0xe0
>  [] ? __vunmap+0x8f/0xe0
>  [] load_module+0x1a92/0x23b0
>  [] ? copy_module_from_fd.isra.46+0x109/0x1a0
>  [] SyS_finit_module+0x8d/0xd0
>  [] ? vm_mmap_pgoff+0x93/0xb0
>  [] sysenter_do_call+0x12/0x16
>
> Feel free to prod me for further details.

This does not ring any bells to me (but that doesn't prove anything). A
bisect result would be awesome.

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank

[Christian König]

Am 01.07.2014 10:14, schrieb Michel D?nzer:
> From: Michel D?nzer 
>
> But move the programming back to the vertical blank interrupt handler.
> And signal the flip as being completed immediately after programming it
> to the hardware.
>
> This way we don't have to guess whether or not the hardware will execute
> the flip in a given vertical blank period, avoiding a whole lot of
> trouble.
>
> Also, not using the page flip interrupt anymore avoids problems due to
> completing page flips earlier than expected by userspace.
>
> Signed-off-by: Michel D?nzer 

I would say to let's nuke rdev->irq.pflip as well and just rely on the 
flip_status to track weather or not there is an page flip scheduled.

Apart from that the two patches look good to me,
Christian.

> ---
>   drivers/gpu/drm/radeon/atombios_crtc.c  | 28 ---
>   drivers/gpu/drm/radeon/cik.c| 58 +++---
>   drivers/gpu/drm/radeon/evergreen.c  | 86 
> +
>   drivers/gpu/drm/radeon/r100.c   | 48 +++---
>   drivers/gpu/drm/radeon/r600.c   | 18 +--
>   drivers/gpu/drm/radeon/radeon.h |  3 +-
>   drivers/gpu/drm/radeon/radeon_asic.c| 22 -
>   drivers/gpu/drm/radeon/radeon_asic.h|  4 --
>   drivers/gpu/drm/radeon/radeon_display.c | 51 ++-
>   drivers/gpu/drm/radeon/radeon_mode.h|  1 -
>   drivers/gpu/drm/radeon/rs600.c  | 28 +++
>   drivers/gpu/drm/radeon/rv770.c  | 24 ++---
>   drivers/gpu/drm/radeon/si.c | 52 +++-
>   13 files changed, 59 insertions(+), 364 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
> b/drivers/gpu/drm/radeon/atombios_crtc.c
> index e911898..65cfdbb 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -1284,6 +1284,10 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
>   break;
>   }
>   
> + /* Make sure updates happen at vertical blank */
> + WREG32(EVERGREEN_GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset, 0);
> + WREG32(EVERGREEN_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
> +
>   WREG32(EVERGREEN_GRPH_PRIMARY_SURFACE_ADDRESS_HIGH + 
> radeon_crtc->crtc_offset,
>  upper_32_bits(fb_location));
>   WREG32(EVERGREEN_GRPH_SECONDARY_SURFACE_ADDRESS_HIGH + 
> radeon_crtc->crtc_offset,
> @@ -1321,15 +1325,6 @@ static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
>   WREG32(EVERGREEN_VIEWPORT_SIZE + radeon_crtc->crtc_offset,
>  (viewport_w << 16) | viewport_h);
>   
> - /* pageflip setup */
> - /* make sure flip is at vb rather than hb */
> - tmp = RREG32(EVERGREEN_GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset);
> - tmp &= ~EVERGREEN_GRPH_SURFACE_UPDATE_H_RETRACE_EN;
> - WREG32(EVERGREEN_GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset, tmp);
> -
> - /* set pageflip to happen anywhere in vblank interval */
> - WREG32(EVERGREEN_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
> -
>   if (!atomic && fb && fb != crtc->primary->fb) {
>   radeon_fb = to_radeon_framebuffer(fb);
>   rbo = gem_to_radeon_bo(radeon_fb->obj);
> @@ -1360,7 +1355,7 @@ static int avivo_crtc_do_set_base(struct drm_crtc *crtc,
>   uint64_t fb_location;
>   uint32_t fb_format, fb_pitch_pixels, tiling_flags;
>   u32 fb_swap = R600_D1GRPH_SWAP_ENDIAN_NONE;
> - u32 tmp, viewport_w, viewport_h;
> + u32 viewport_w, viewport_h;
>   int r;
>   
>   /* no fb bound */
> @@ -1451,6 +1446,10 @@ static int avivo_crtc_do_set_base(struct drm_crtc 
> *crtc,
>   else
>   WREG32(AVIVO_D2VGA_CONTROL, 0);
>   
> + /* Make sure updates happen at vertical blank */
> + WREG32(AVIVO_D1GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset, 0);
> + WREG32(AVIVO_D1MODE_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
> +
>   if (rdev->family >= CHIP_RV770) {
>   if (radeon_crtc->crtc_id) {
>   WREG32(R700_D2GRPH_PRIMARY_SURFACE_ADDRESS_HIGH, 
> upper_32_bits(fb_location));
> @@ -1490,15 +1489,6 @@ static int avivo_crtc_do_set_base(struct drm_crtc 
> *crtc,
>   WREG32(AVIVO_D1MODE_VIEWPORT_SIZE + radeon_crtc->crtc_offset,
>  (viewport_w << 16) | viewport_h);
>   
> - /* pageflip setup */
> - /* make sure flip is at vb rather than hb */
> - tmp = RREG32(AVIVO_D1GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset);
> - tmp &= ~AVIVO_D1GRPH_SURFACE_UPDATE_H_RETRACE_EN;
> - WREG32(AVIVO_D1GRPH_FLIP_CONTROL + radeon_crtc->crtc_offset, tmp);
> -
> - /* set pageflip to happen anywhere in vblank interval */
> - WREG32(AVIVO_D1MODE_MASTER_UPDATE_MODE + radeon_crtc->crtc_offset, 0);
> -
>   if (!atomic && fb && fb != crtc->primary->fb) {
>   radeon_fb = to_radeon_framebuffer(fb);
>   rbo = gem_to_radeon_bo(radeon_fb->obj);
> diff --git 

[PATCH] drm/radeon: add user pointer support v2

[Christian König]

Am 30.06.2014 19:35, schrieb Jerome Glisse:
> On Mon, Jun 30, 2014 at 03:04:16PM +0200, Christian K?nig wrote:
>> From: Christian K?nig 
>>
>> This patch adds an IOCTL for turning a pointer supplied by
>> userspace into a buffer object.
>>
>> It works similar to the recently added userptr support for i915,
>> so it also imposes several restrictions upon the memory being mapped:
>>
>> 1. It must be page aligned (both start/end addresses, i.e ptr and size).
>>
>> 2. It must be normal system memory, not a pointer into another map of IO
>> space (e.g. it must not be a GTT mmapping of another object).
>>
>> 3. The BO is mapped into GTT, so the maximum amount of memory mapped at
>> all times is still the GTT limit.
>>
>> Exporting and sharing as well as mapping of buffer objects created by
>> this function is forbidden and results in an -EPERM.
>>
>> In difference to the i915 implementation we don't use an interval tree to
>> manage all the buffers objects created and instead just register a separate
>> MMU notifier callback for each BO so that buffer objects are invalidated
>> whenever any modification is made to the processes page table. This probably
>> needs further optimization.
>>
>> Please review and / or comment.
> NAK, this is kind of an horror show. I should probably take a look at
> Intel code too.

Yeah, I'm not to keen about the approach either and would rather prefer 
using the IOMMU, but unfortunately that isn't available under all use 
cases we need to be able to handle.

BTW: Here is the link to the initial commit of the Intel implementation 
as it is in Linus tree: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5cc9ed4b9a7ac579362ccebac67f7a4cdb36de06

> First registering one notifier per bo is a bad idea, it is not what you
> want to do.

I know, the Intel guys use a single registration for each process and an 
interval tree to lockup all the BOs affected.

I just wanted to keep the implementation simple and stupid for now and 
first get feedback about the approach in general (to save time if the 
whole approach won't be accepted at all and your reaction indeed 
confirms that this was a good idea).

>> [SNIP]
>> @@ -176,8 +181,15 @@ static int radeon_cs_parser_relocs(struct 
>> radeon_cs_parser *p)
>>  if (p->cs_flags & RADEON_CS_USE_VM)
>>  p->vm_bos = radeon_vm_get_bos(p->rdev, p->ib.vm,
>>>validated);
>> +if (need_mmap_lock)
>> +down_read(>mm->mmap_sem);
>> +
>> +r = radeon_bo_list_validate(p->rdev, >ticket, >validated, 
>> p->ring);
>>   
>> -return radeon_bo_list_validate(p->rdev, >ticket, >validated, 
>> p->ring);
>> +if (need_mmap_lock)
>> +up_read(>mm->mmap_sem);
>> +
>> +return r;
>>   }
> So the mmap lock protect almost nothing here. Once things are validated
> nothing forbid the userspace to unmap the range containing the user bo.

As far as I understand it (and I'm probably not so deep into the MM code 
as you, so correct me if I'm wrong) unmapping the range would result in 
an invalidate_range_start callback and this callback in turn validates 
the BO into the CPU domain again. So it actually blocks for the GPU 
operation to be completed, marks the pages in question as dirty and then 
unpins them.

This should protected us anything nasty to happen in the case of a 
unmap(), fork() etc...

>>   
>>   static int radeon_cs_get_ring(struct radeon_cs_parser *p, u32 ring, s32 
>> priority)
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 6e30174..355aa67 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -112,6 +112,9 @@ int radeon_gem_object_open(struct drm_gem_object *obj,
>>  struct drm_file *file_priv);
>>   void radeon_gem_object_close(struct drm_gem_object *obj,
>>  struct drm_file *file_priv);
>> +struct dma_buf *radeon_gem_prime_export(struct drm_device *dev,
>> +struct drm_gem_object *gobj,
>> +int flags);
> Use tab not space there is already enough broken tab/space in radeon
> kernel as it is. I always tried to keep it consistant.

Fixed, thanks for the hint.

>> [SNIP]
>> +static void radeon_bo_mn_release(struct mmu_notifier *mn,
>> + struct mm_struct *mm)
>> +{
>> +struct radeon_bo *bo = container_of(mn, struct radeon_bo, mn);
>> +
>> +bo->mn.ops = NULL;
>> +}
>> +
>> +static void radeon_bo_mn_invalidate_range_start(struct mmu_notifier *mn,
>> +struct mm_struct *mm,
>> +unsigned long start,
>> +unsigned long end)
>> +{
>> +struct radeon_bo *bo = container_of(mn, struct radeon_bo, mn);
>> +int r;
>> +
>> +/* TODO: optimize! */
>> 

[PATCH] drm/radeon: use RADEON_MAX_CRTCS, RADEON_MAX_AFMT_BLOCKS

[Alex Deucher]

On Sun, Jun 29, 2014 at 3:02 PM, Stefan Br?ns
 wrote:
>
> Signed-off-by: Stefan Br?ns 

Both patches applied.  I've fixed this one to compile.  Please make
sure your patches compile.  thanks.

Alex

> ---
>  drivers/gpu/drm/radeon/radeon_mode.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
> b/drivers/gpu/drm/radeon/radeon_mode.h
> index ad0e4b8..79b8c7e 100644
> --- a/drivers/gpu/drm/radeon/radeon_mode.h
> +++ b/drivers/gpu/drm/radeon/radeon_mode.h
> @@ -233,8 +233,8 @@ struct radeon_mode_info {
> struct card_info *atom_card_info;
> enum radeon_connector_table connector_table;
> bool mode_config_initialized;
> -   struct radeon_crtc *crtcs[6];
> -   struct radeon_afmt *afmt[7];
> +   struct radeon_crtc *crtcs[RADEON_MAX_CRTCS];
> +   struct radeon_afmt *afmt[RADEON_MAX_AFMT_BLOCKS];
> /* DVI-I properties */
> struct drm_property *coherent_mode_property;
> /* DAC enable load detect */
> --
> 1.8.4.5
>
> --
> Stefan Br?ns  /  Bergstra?e 21  /  52062 Aachen
> phone: +49 241 53809034 mobile: +49 151 50412019
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie

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

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

--- Comment #13 from Marek Ol??k  ---
(In reply to comment #12)
> FYI I see a similar GPU stalls/display blanks with an upgrade from 10.1.4 ->
> 10.2.1. I am on Verde with VERDE_mc2.bin.
> 
> I started bisecting, but it takes me about a day to judge good vs bad, and
> as I have around 1000 commits in front of me, this will take about 10 days.
> 
> I am also on Arch. xorg-server=1.15.1, xf86-video-ati=7.3.0. linux=3.15.2.

Kernel 3.15 is indeed unstable on Cape Verde. We know where the problem is. If
kernel 3.14 doesn't hang the GPU for you, it's the same problem.

-- 
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/20140701/8e725a24/attachment.html>

[PATCH] drm/radeon: add user pointer support v2

[Jerome Glisse]

On Tue, Jul 01, 2014 at 11:49:18AM +0200, Christian K?nig wrote:
> Am 30.06.2014 19:35, schrieb Jerome Glisse:
> >On Mon, Jun 30, 2014 at 03:04:16PM +0200, Christian K?nig wrote:
> >>From: Christian K?nig 
> >>
> >>This patch adds an IOCTL for turning a pointer supplied by
> >>userspace into a buffer object.
> >>
> >>It works similar to the recently added userptr support for i915,
> >>so it also imposes several restrictions upon the memory being mapped:
> >>
> >>1. It must be page aligned (both start/end addresses, i.e ptr and size).
> >>
> >>2. It must be normal system memory, not a pointer into another map of IO
> >>space (e.g. it must not be a GTT mmapping of another object).
> >>
> >>3. The BO is mapped into GTT, so the maximum amount of memory mapped at
> >>all times is still the GTT limit.
> >>
> >>Exporting and sharing as well as mapping of buffer objects created by
> >>this function is forbidden and results in an -EPERM.
> >>
> >>In difference to the i915 implementation we don't use an interval tree to
> >>manage all the buffers objects created and instead just register a separate
> >>MMU notifier callback for each BO so that buffer objects are invalidated
> >>whenever any modification is made to the processes page table. This probably
> >>needs further optimization.
> >>
> >>Please review and / or comment.
> >NAK, this is kind of an horror show. I should probably take a look at
> >Intel code too.
> 
> Yeah, I'm not to keen about the approach either and would rather
> prefer using the IOMMU, but unfortunately that isn't available under
> all use cases we need to be able to handle.
> 
> BTW: Here is the link to the initial commit of the Intel
> implementation as it is in Linus tree: 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5cc9ed4b9a7ac579362ccebac67f7a4cdb36de06
> 
> >First registering one notifier per bo is a bad idea, it is not what you
> >want to do.
> 
> I know, the Intel guys use a single registration for each process
> and an interval tree to lockup all the BOs affected.
> 
> I just wanted to keep the implementation simple and stupid for now
> and first get feedback about the approach in general (to save time
> if the whole approach won't be accepted at all and your reaction
> indeed confirms that this was a good idea).
> 
> >>[SNIP]
> >>@@ -176,8 +181,15 @@ static int radeon_cs_parser_relocs(struct 
> >>radeon_cs_parser *p)
> >>if (p->cs_flags & RADEON_CS_USE_VM)
> >>p->vm_bos = radeon_vm_get_bos(p->rdev, p->ib.vm,
> >>  >validated);
> >>+   if (need_mmap_lock)
> >>+   down_read(>mm->mmap_sem);
> >>+
> >>+   r = radeon_bo_list_validate(p->rdev, >ticket, >validated, 
> >>p->ring);
> >>-   return radeon_bo_list_validate(p->rdev, >ticket, >validated, 
> >>p->ring);
> >>+   if (need_mmap_lock)
> >>+   up_read(>mm->mmap_sem);
> >>+
> >>+   return r;
> >>  }
> >So the mmap lock protect almost nothing here. Once things are validated
> >nothing forbid the userspace to unmap the range containing the user bo.
> 
> As far as I understand it (and I'm probably not so deep into the MM
> code as you, so correct me if I'm wrong) unmapping the range would
> result in an invalidate_range_start callback and this callback in
> turn validates the BO into the CPU domain again. So it actually
> blocks for the GPU operation to be completed, marks the pages in
> question as dirty and then unpins them.
> 
> This should protected us anything nasty to happen in the case of a
> unmap(), fork() etc...

Thing is nothing forbid from a new cs ioctl to happen right after
the radeon range_start callback but before the core mm code that
was about to do something. The mmap_sem will protect you from fork
or munmap but not from otherthing.

> 
> >>  static int radeon_cs_get_ring(struct radeon_cs_parser *p, u32 ring, s32 
> >> priority)
> >>diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
> >>b/drivers/gpu/drm/radeon/radeon_drv.c
> >>index 6e30174..355aa67 100644
> >>--- a/drivers/gpu/drm/radeon/radeon_drv.c
> >>+++ b/drivers/gpu/drm/radeon/radeon_drv.c
> >>@@ -112,6 +112,9 @@ int radeon_gem_object_open(struct drm_gem_object *obj,
> >>struct drm_file *file_priv);
> >>  void radeon_gem_object_close(struct drm_gem_object *obj,
> >>struct drm_file *file_priv);
> >>+struct dma_buf *radeon_gem_prime_export(struct drm_device *dev,
> >>+struct drm_gem_object *gobj,
> >>+int flags);
> >Use tab not space there is already enough broken tab/space in radeon
> >kernel as it is. I always tried to keep it consistant.
> 
> Fixed, thanks for the hint.
> 
> >>[SNIP]
> >>+static void radeon_bo_mn_release(struct mmu_notifier *mn,
> >>+struct mm_struct *mm)
> >>+{
> >>+   struct radeon_bo *bo = container_of(mn, struct radeon_bo, mn);
> >>+
> >>+   bo->mn.ops = NULL;
> >>+}
> >>+
> 

[PULL] drm-intel-next

[Jani Nikula]

Hi Dave -

drm-intel-next-2014-06-20:
- Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and
  flip events. This is prep work for proper PSR support and should also be
  useful for DRRS
- Runtime suspend hardware on system suspend to support the new SOix sleep
  states, from Jesse.
- PSR updates for broadwell (Rodrigo)
- Universal plane support for cursors (Matt Roper), including core drm patches.
- Prefault gtt mappings (Chris)
- baytrail write-enable pte bit support (Akash Goel)
- mmio based flips (Sourab Gupta) instead of blitter ring flips
- interrupt handling race fixes (Oscar Mateo)

And old, not yet merged features from the previous round:
- rps/turbo support for chv (Deepak)
- some other straggling chv patches (Ville)
- proper universal plane conversion for the primary plane (Matt Roper)
- ppgtt on vlv from Jesse
- pile of cleanups, little fixes for insane corner cases and improved debug
  support all over

This is the first i915 pull request for 3.17. (Also my first feature
pull request, yay!)

As discussed, it contains acpi-next as a dependency for Jesse's S0ix
work through these merges (should not conflict, fingers crossed):

Daniel Vetter (22):
  Merge commit 'e81a0e771c10de86fdb52c6baf534ff5fdeec72c' into topic/soix
  Merge branch 'topic/soix' into drm-intel-next-queued


BR,
Jani.


The following changes since commit bc1dfff04a5d4064ba0db1fab13f84ab4f333d2b:

  Merge branch 'drm-nouveau-next' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next (2014-06-11 
16:28:10 +1000)

are available in the git repository at:


  git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-06-20

for you to fetch changes up to 34882298b93e998d5fccde852b860e8fbe6c8f6b:

  drm/i915: Update DRIVER_DATE to 20140620 (2014-06-20 10:36:06 +0200)


- Accurate frontbuffer tracking and frontbuffer rendering invalidate, flush and
  flip events. This is prep work for proper PSR support and should also be
  useful for DRRS
- Runtime suspend hardware on system suspend to support the new SOix sleep
  states, from Jesse.
- PSR updates for broadwell (Rodrigo)
- Universal plane support for cursors (Matt Roper), including core drm patches.
- Prefault gtt mappings (Chris)
- baytrail write-enable pte bit support (Akash Goel)
- mmio based flips (Sourab Gupta) instead of blitter ring flips
- interrupt handling race fixes (Oscar Mateo)

And old, not yet merged features from the previous round:
- rps/turbo support for chv (Deepak)
- some other straggling chv patches (Ville)
- proper universal plane conversion for the primary plane (Matt Roper)
- ppgtt on vlv from Jesse
- pile of cleanups, little fixes for insane corner cases and improved debug
  support all over


Akash Goel (1):
  drm/i915: Added write-enable pte bit supportt

Brad Volkin (1):
  drm/i915: Add some L3 registers to the parser whitelist

Chris Wilson (6):
  drm/i915: Check for a NULL shared dpll before dereferencing
  drm/i915: Use the .release hook to drop the stolen drm_mm tracking
  drm/i915: Prefault the entire object on first page fault
  drm: Avoid NULL deference when disabling a plane from userspace
  drm/i915: Simplify i915_gem_release_all_mmaps()
  drm/i915: Simplify processing of the golden render context state

Christoph Jaeger (1):
  drm/i915: Fix memory leak in intel_dsi_init() error path

Daisy Sun (1):
  drm/i915: Broaden FBC resolution limit to 4096*4096

Damien Lespiau (2):
  drm/i915: Make intel_dsi_init() return void
  drm/i915: Use %c in a format string for the pipe name

Daniel Vetter (22):
  drm/i915: Fix context locking in debugfs
  drm/i915: Drop locking around fbdev-fb in debugfs
  drm/i915: runtime PM support for DPMS
  drm/i915: Add #defines for short/long pulse on gmch platforms
  Merge commit 'e81a0e771c10de86fdb52c6baf534ff5fdeec72c' into topic/soix
  drm/i915: Unifiy GT powersave suspend logic
  drm/i915: Only wait one vblank when disabling crc if the pipe is on
  drm/i915: Update DRIVER_DATE to 20140606
  drm/i915: Fix comment about our plane remapping on gen2/3
  drm/i915: Add missing statics to recent psr functions
  drm/i915: Grab dev->struct_mutex in i915_gem_pageflip_info
  drm/i915: Don't BUG_ON in i915_gem_obj_offset
  Merge branch 'topic/soix' into drm-intel-next-queued
  drm/i915: Drop unecessary complexity from psr_inactivate
  drm/i915: Ditch intel_edp_psr_update
  drm/i915: Drop schedule_back from psr_exit
  drm/i915: Introduce accurate frontbuffer tracking
  drm/i915: Print obj->frontbuffer_bits in debugfs output
  drm/i915: Properly track domain of the fbcon fb
  drm/i915: Use new frontbuffer bits to increase pll clock
  drm/i915: Track frontbuffer invalidation/flushing
  drm/i915: Update DRIVER_DATE to 

[PATCH 4/7] Exynos: add support for 'domain-always-on' property

[Marek Szyprowski]

Hello,

On 2014-07-01 10:52, Tobias Jakobi wrote:
> Hello Marek,
>
> I think you had a similar patch in the tizen tree, but according to
> Tomasz Figa, it was considered a hack. I don't quite see how this is
> different.
>
> Also, if I have been following the discussion correctly, then the
> powerdomain issue essentially is about the question which SoC block
> needs the LCD0 domain and how the proper power on/off sequences should
> look like.
>
> At least the mixer power issue, which I pointed out some time ago, seems
> to be deal with now:
> https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-next=381be025ac1a6dc8efebdf146ced0d4a6007f77b

Well, that patch solves power on/off sequence issue with mixer and hdmi,
but it didn't solve the issue with additional managing of power domain
on/off. You can check that if you remove always on property, system will
freeze when hdmi cable is connected for the second time. I've investigated
it for some time, but right now I didn't find any 100% reliable solution
other than keeping the power domain enabled all the time. At least for
now, this patch lets you use HDMI without any stability issues.

I've only found that there are still at least 2 issues with power domains.
One is Mixer/Video Processor dependency on LCD0 domain, second is the proper
power on/off sequence of HDMI/Mixer and TV domain. Forcing both domains to
'always on' workarounds both issues for now. Right now I have no better
idea.

Later, once the proper sequence is found we can remove those properties
from Odroid DTS.

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

[PATCH] exynos: Put a stop to the userptr heresy.

[Jerome Glisse]

On Tue, Jul 01, 2014 at 05:55:25PM +0900, Inki Dae wrote:
> 
> Hi Jerome,
> 
> 
> On 2014? 07? 01? 06:46, j.glisse at gmail.com wrote:
> > From: Jerome Glisse 
> >
> > get_user_pages gives no garanty that page it returns are still
> > the one backing the vma by the time it returns. Thus any ioctl
> 
> One of pages from get_user_pages() could be migrated? I think all the
> pages are pinned so that they cannot be migrated. If not such case, is
> there other case I missed?

I thought the ksm or gdb path were forcing unmap and replace but they
still abide by the pin so while page will not be replace you are still
violating few things. First you are pining memory without any kind of
accouting from memcg point of view hence userspace can use that as a
vector of attack to deplete memory.

You also ignore any munmap that might happen, any munmap will not care
about the page being pin or not. The vma will disappear.

Nor you respect the page being remapped read only for page write back
allowing the gpu to write to the page while I/O is in progress.

> 
> One more thing, do you think this issue cannot be resolved so you are
> trying to remove userptr feature from g2d driver?
> 

I am just thinking that this is a somewhat evil api, i understand how
nice it is for things like zero copy upload/download. But it allows to
go around some of the memory policy set by other part of the kernel.

But i guess that given you map/unmap accross cmd ioctl that is close
to the direct-io usage pattern and thus can be forgiven.

Note that if you were to start using GUP-fast then you will also have
to consider the mmu_notifier range invalidation.

Cheers,
J?r?me

> Thanks,
> Inki Dae
> 
> > that rely on this behavior is broken and rely on pure luck. To
> > avoid any false hope from userspace stop such useage by simply
> > flat out returning -EFAULT. Better to have a reliable behavior
> > than to depend on pure luck and currently observed behavior of
> > mm code.
> >
> > Note this was not even compile tested but i think i did update
> > all places.
> >
> > Signed-off-by: J?r?me Glisse 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h |   1 -
> >  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 277 
> > +---
> >  drivers/gpu/drm/exynos/exynos_drm_gem.c |  60 ---
> >  drivers/gpu/drm/exynos/exynos_drm_gem.h |  20 ---
> >  4 files changed, 3 insertions(+), 355 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > index 36535f3..7b55e89 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > @@ -233,7 +233,6 @@ struct exynos_drm_g2d_private {
> > struct device   *dev;
> > struct list_headinuse_cmdlist;
> > struct list_headevent_list;
> > -   struct list_headuserptr_list;
> >  };
> >
> >  struct exynos_drm_ipp_private {
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > index 8001587..d0be6dc 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> > @@ -118,9 +118,6 @@
> >  #define G2D_CMDLIST_POOL_SIZE  (G2D_CMDLIST_SIZE * 
> > G2D_CMDLIST_NUM)
> >  #define G2D_CMDLIST_DATA_NUM   (G2D_CMDLIST_SIZE / sizeof(u32) 
> > - 2)
> >
> > -/* maximum buffer pool size of userptr is 64MB as default */
> > -#define MAX_POOL   (64 * 1024 * 1024)
> > -
> >  enum {
> > BUF_TYPE_GEM = 1,
> > BUF_TYPE_USERPTR,
> > @@ -185,19 +182,6 @@ struct drm_exynos_pending_g2d_event {
> > struct drm_exynos_g2d_event event;
> >  };
> >
> > -struct g2d_cmdlist_userptr {
> > -   struct list_headlist;
> > -   dma_addr_t  dma_addr;
> > -   unsigned long   userptr;
> > -   unsigned long   size;
> > -   struct page **pages;
> > -   unsigned intnpages;
> > -   struct sg_table *sgt;
> > -   struct vm_area_struct   *vma;
> > -   atomic_trefcount;
> > -   boolin_pool;
> > -   boolout_of_list;
> > -};
> >  struct g2d_cmdlist_node {
> > struct list_headlist;
> > struct g2d_cmdlist  *cmdlist;
> > @@ -242,7 +226,6 @@ struct g2d_data {
> > struct kmem_cache   *runqueue_slab;
> >
> > unsigned long   current_pool;
> > -   unsigned long   max_pool;
> >  };
> >
> >  static int g2d_init_cmdlist(struct g2d_data *g2d)
> > @@ -354,232 +337,6 @@ add_to_list:
> > list_add_tail(>event->base.link, _priv->event_list);
> >  }
> >
> > -static void g2d_userptr_put_dma_addr(struct drm_device *drm_dev,
> > -   unsigned long obj,
> > -   bool force)
> > -{
> > -   struct g2d_cmdlist_userptr *g2d_userptr =
> > -   (struct g2d_cmdlist_userptr *)obj;
> > -
> 

[PATCH 1/7] clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks

[Marek Szyprowski]

Hello,

On 2014-07-01 10:46, Tobias Jakobi wrote:
> Hello Marek,
>
> I think this particular clock setup should already be handled by this patch:
> http://www.spinics.net/lists/arm-kernel/msg320013.html
>
> Or am I missing something here?

The patch you have pointed requires adding support for SET_PARENT_PARENT
feature to clock core, which has not been accepted yet. Only then Exynod
DRM drivers can be updated to correctly handle the changed clock tree.

My approach is to introduce minimal changes and use the code which is
already in the exynos drm/hdmi driver (it already manages 'mout_hdmi/mixer'
clocks). If other solution is finally accepted, the code can be simplified
and mout_hdmi/mixer clocks simply ignored. For now - my changes are needed
to get HDMI output working and have least dependencies.

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

[PATCH 4/7] Exynos: add support for 'domain-always-on' property

[Tobias Jakobi]

Hello Marek,

I think you had a similar patch in the tizen tree, but according to
Tomasz Figa, it was considered a hack. I don't quite see how this is
different.

Also, if I have been following the discussion correctly, then the
powerdomain issue essentially is about the question which SoC block
needs the LCD0 domain and how the proper power on/off sequences should
look like.

At least the mixer power issue, which I pointed out some time ago, seems
to be deal with now:
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-next=381be025ac1a6dc8efebdf146ced0d4a6007f77b

With best wishes,
Tobias




Marek Szyprowski wrote:
> This patch adds support for domain-always-on property to Exynos power
> domain driver. Domains with this property as always kept enabled.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 2 ++
>  arch/arm/mach-exynos/pm_domains.c | 6 +-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
> b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> index 5216b419016a..b25d9b1ce471 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> @@ -8,6 +8,8 @@ Required Properties:
>  * samsung,exynos4210-pd - for exynos4210 type power domain.
>  - reg: physical base address of the controller and length of memory mapped
>  region.
> +Optional properties:
> +- domain-always-on:  keeps the domain always enabled
>  
>  Node of a device using power domains must have a samsung,power-domain 
> property
>  defined with a phandle to respective power domain.
> diff --git a/arch/arm/mach-exynos/pm_domains.c 
> b/arch/arm/mach-exynos/pm_domains.c
> index fe6570ebbdde..279b008de02f 100644
> --- a/arch/arm/mach-exynos/pm_domains.c
> +++ b/arch/arm/mach-exynos/pm_domains.c
> @@ -151,6 +151,7 @@ static __init int exynos4_pm_init_power_domain(void)
>   struct device_node *np;
>  
>   for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
> + struct dev_power_governor *gov = NULL;
>   struct exynos_pm_domain *pd;
>   int on;
>  
> @@ -163,6 +164,9 @@ static __init int exynos4_pm_init_power_domain(void)
>   return -ENOMEM;
>   }
>  
> + if (of_property_read_bool(np, "domain-always-on"))
> + gov = _domain_always_on_gov;
> +
>   pd->pd.name = kstrdup(np->name, GFP_KERNEL);
>   pd->name = pd->pd.name;
>   pd->base = of_iomap(np, 0);
> @@ -174,7 +178,7 @@ static __init int exynos4_pm_init_power_domain(void)
>  
>   on = __raw_readl(pd->base + 0x4) & S5P_INT_LOCAL_PWR_EN;
>  
> - pm_genpd_init(>pd, NULL, !on);
> + pm_genpd_init(>pd, gov, !on);
>   }
>  
>   bus_register_notifier(_bus_type, _nb);
> 

[PATCH 1/7] clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks

[Tobias Jakobi]

Hello Marek,

I think this particular clock setup should already be handled by this patch:
http://www.spinics.net/lists/arm-kernel/msg320013.html

Or am I missing something here?

With best wishes,
Tobias


Marek Szyprowski wrote:
> This patch adds support for exporting mout_hdmi and mout_mixer to device
> tree. Access to those clocks is required to correctly setup HDMI module
> on Exynos 4210 and 4x12 SoCs.
> 
> Signed-off-by: Marek Szyprowski 
> CC: Mike Turquette 
> CC: Tomasz Figa 
> ---
>  drivers/clk/samsung/clk-exynos4.c   | 4 ++--
>  include/dt-bindings/clock/exynos4.h | 2 ++
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/clk/samsung/clk-exynos4.c 
> b/drivers/clk/samsung/clk-exynos4.c
> index 4f150c9dd38c..a30a779869eb 100644
> --- a/drivers/clk/samsung/clk-exynos4.c
> +++ b/drivers/clk/samsung/clk-exynos4.c
> @@ -440,7 +440,7 @@ static struct samsung_fixed_rate_clock 
> exynos4210_fixed_rate_clks[] __initdata =
>  static struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
>   MUX_FA(CLK_MOUT_APLL, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
>   CLK_SET_RATE_PARENT, 0, "mout_apll"),
> - MUX(0, "mout_hdmi", mout_hdmi_p, SRC_TV, 0, 1),
> + MUX(CLK_MOUT_HDMI, "mout_hdmi", mout_hdmi_p, SRC_TV, 0, 1),
>   MUX(0, "mout_mfc1", sclk_evpll_p, SRC_MFC, 4, 1),
>   MUX(0, "mout_mfc", mout_mfc_p, SRC_MFC, 8, 1),
>   MUX_F(CLK_MOUT_G3D1, "mout_g3d1", sclk_evpll_p, SRC_G3D, 4, 1,
> @@ -463,7 +463,7 @@ static struct samsung_mux_clock exynos4210_mux_clks[] 
> __initdata = {
>   MUX(0, "mout_aclk100", sclk_ampll_p4210, SRC_TOP0, 16, 1),
>   MUX(0, "mout_aclk160", sclk_ampll_p4210, SRC_TOP0, 20, 1),
>   MUX(0, "mout_aclk133", sclk_ampll_p4210, SRC_TOP0, 24, 1),
> - MUX(0, "mout_mixer", mout_mixer_p4210, SRC_TV, 4, 1),
> + MUX(CLK_MOUT_MIXER, "mout_mixer", mout_mixer_p4210, SRC_TV, 4, 1),
>   MUX(0, "mout_dac", mout_dac_p4210, SRC_TV, 8, 1),
>   MUX(0, "mout_g2d0", sclk_ampll_p4210, E4210_SRC_IMAGE, 0, 1),
>   MUX(0, "mout_g2d1", sclk_evpll_p, E4210_SRC_IMAGE, 4, 1),
> diff --git a/include/dt-bindings/clock/exynos4.h 
> b/include/dt-bindings/clock/exynos4.h
> index 1106ca540a96..5bfb3509ee3c 100644
> --- a/include/dt-bindings/clock/exynos4.h
> +++ b/include/dt-bindings/clock/exynos4.h
> @@ -229,6 +229,8 @@
>  #define CLK_MOUT_G3D1393
>  #define CLK_MOUT_G3D 394
>  #define CLK_ACLK400_MCUISP   395 /* Exynos4x12 only */
> +#define CLK_MOUT_HDMI396
> +#define CLK_MOUT_MIXER   397
>  
>  /* div clocks */
>  #define CLK_DIV_ISP0 450 /* Exynos4x12 only */
> 

[PATCH v4 1/4] drm/crtc: Add property for aspect ratio

[Vandana Kannan]

Hi Thierry/Daniel,

Please help review this patch series on aspect ratio and let me know
your inputs..

1. http://lists.freedesktop.org/archives/dri-devel/2014-June/061576.html
- All review comments (from Thierry) addressed.
2. http://lists.freedesktop.org/archives/dri-devel/2014-June/061217.html
- R-b from Thierry
3. http://lists.freedesktop.org/archives/dri-devel/2014-June/061577.html
4. http://lists.freedesktop.org/archives/dri-devel/2014-June/061592.html
- R-b from Sagar

Thanks,
Vandana

On Jun-11-2014 10:46 AM, Kannan, Vandana wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property and code to create the
> property.
> 
> v2: Thierry's review comments.
>   - Made aspect ratio enum generic instead of HDMI/CEA specfic
>   - Removed usage of temporary aspect_ratio variable
> 
> v3: Thierry's review comments.
>   - Fixed indentation
> 
> v4: Thierry's review comments.
>   - Return ENOMEM when property creation fails
> 
> Signed-off-by: Vandana Kannan 
> Cc: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_crtc.c  | 33 +
>  include/drm/drm_crtc.h  |  2 ++
>  include/uapi/drm/drm_mode.h |  5 +
>  3 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 37a3e07..a745df3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -139,6 +139,12 @@ static const struct drm_prop_enum_list 
> drm_scaling_mode_enum_list[] =
>   { DRM_MODE_SCALE_ASPECT, "Full aspect" },
>  };
>  
> +static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
> + { DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
> + { DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
> + { DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
> +};
> +
>  /*
>   * Non-global properties, but "required" for certain connectors.
>   */
> @@ -1344,6 +1350,33 @@ int drm_mode_create_scaling_mode_property(struct 
> drm_device *dev)
>  EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
>  
>  /**
> + * drm_mode_create_aspect_ratio_property - create aspect ratio property
> + * @dev: DRM device
> + *
> + * Called by a driver the first time it's needed, must be attached to desired
> + * connectors.
> + *
> + * Returns:
> + * Zero on success, errno on failure.
> + */
> +int drm_mode_create_aspect_ratio_property(struct drm_device *dev)
> +{
> + if (dev->mode_config.aspect_ratio_property)
> + return 0;
> +
> + dev->mode_config.aspect_ratio_property =
> + drm_property_create_enum(dev, 0, "aspect ratio",
> + drm_aspect_ratio_enum_list,
> + ARRAY_SIZE(drm_aspect_ratio_enum_list));
> +
> + if (dev->mode_config.aspect_ratio_property == NULL)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
> +
> +/**
>   * drm_mode_create_dirty_property - create dirty property
>   * @dev: DRM device
>   *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5c1c31c..1149617 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -801,6 +801,7 @@ struct drm_mode_config {
>  
>   /* Optional properties */
>   struct drm_property *scaling_mode_property;
> + struct drm_property *aspect_ratio_property;
>   struct drm_property *dirty_info_property;
>  
>   /* dumb ioctl parameters */
> @@ -971,6 +972,7 @@ extern int drm_mode_create_dvi_i_properties(struct 
> drm_device *dev);
>  extern int drm_mode_create_tv_properties(struct drm_device *dev, int 
> num_formats,
>char *formats[]);
>  extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> +extern int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
>  extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
>  extern const char *drm_get_encoder_name(const struct drm_encoder *encoder);
>  
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index f104c26..943b377 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -88,6 +88,11 @@
>  #define DRM_MODE_SCALE_CENTER2 /* Centered, no scaling */
>  #define DRM_MODE_SCALE_ASPECT3 /* Full screen, preserve 
> aspect */
>  
> +/* Picture aspect ratio options */
> +#define DRM_MODE_PICTURE_ASPECT_NONE 0
> +#define DRM_MODE_PICTURE_ASPECT_4_3  1
> +#define DRM_MODE_PICTURE_ASPECT_16_9 2
> +
>  /* Dithering mode options */
>  #define DRM_MODE_DITHERING_OFF   0
>  #define DRM_MODE_DITHERING_ON1
> 

[PATCH 7/7] ARM: dts: exynos4210-universal_c210: enable hdmi support

[Marek Szyprowski]

From: Tomasz Stanislawski 

This patch adds configuration of hw modules required to enable HDMI
support on Universal C210 board.

Signed-off-by: Tomasz Stanislawski 
Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos4210-universal_c210.dts | 65 +
 1 file changed, 65 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d50eb3aa708e..585082397d5a 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -43,6 +43,14 @@
};
};

+   lcd0-power-domain at 10023C80 {
+   domain-always-on;
+   };
+
+   tv-power-domain at 10023C20 {
+   domain-always-on;
+   };
+
mct at 1005 {
compatible = "none";
};
@@ -487,6 +495,63 @@
status = "okay";
};
};
+
+   hdmi_en: voltage-regulator-hdmi-5v {
+   compatible = "regulator-fixed";
+   regulator-name = "HDMI_5V";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 1 0>;
+   enable-active-high;
+   };
+
+   hdmi_ddc: i2c-ddc {
+   compatible = "i2c-gpio";
+   gpios = < 2 0  3 0>;
+   i2c-gpio,delay-us = <100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   pinctrl-0 = <_ddc_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+   };
+
+   mixer at 12C1 {
+   status = "okay";
+   };
+
+   hdmi at 12D0 {
+   hpd-gpio = < 7 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpd>;
+   hdmi-en-supply = <_en>;
+   vdd-supply = <_reg>;
+   vdd_osc-supply = <_reg>;
+   vdd_pll-supply = <_reg>;
+   ddc = <_ddc>;
+   status = "okay";
+   };
+
+   i2c at 138E {
+   status = "okay";
+   };
+};
+
+_1 {
+   hdmi_hpd: hdmi-hpd {
+   samsung,pins = "gpx3-7";
+   samsung,pin-pud = <0>;
+   };
+};
+
+_0 {
+   i2c_ddc_bus: i2c-ddc-bus {
+   samsung,pins = "gpe4-2", "gpe4-3";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
 };

  {
-- 
1.9.2

[PATCH 6/7] ARM: dts: exynos4412-odroid: enable hdmi support

[Marek Szyprowski]

This patch adds nodes specific to Exynos4412 based Odroid X/X2/U2/U3
boards required for enabling HDMI display.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 52 +
 1 file changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index d1b33a8efa9d..2856242d640a 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -52,6 +52,14 @@
};
};

+   lcd0-power-domain at 10023C80 {
+   domain-always-on;
+   };
+
+   tv-power-domain at 10023C20 {
+   domain-always-on;
+   };
+
watchdog at 1006 {
status = "okay";
};
@@ -186,6 +194,20 @@
regulator-always-on;
};

+   ldo8_reg: ldo at 8 {
+   regulator-compatible = "LDO8";
+   regulator-name = "VDD10_HDMI_1.0V";
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <100>;
+   };
+
+   ldo10_reg: ldo at 10 {
+   regulator-compatible = "LDO10";
+   regulator-name = "VDDQ_MIPIHSI_1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
ldo11_reg: LDO11 {
regulator-name = "VDD18_ABB1_1.8V";
regulator-min-microvolt = <180>;
@@ -332,6 +354,31 @@
ehci: ehci at 1258 {
status = "okay";
};
+
+   mixer: mixer at 12C1 {
+   status = "okay";
+   };
+
+   hdmi at 12D0 {
+   hpd-gpio = < 7 0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpd>;
+   vdd-supply = <_reg>;
+   vdd_osc-supply = <_reg>;
+   vdd_pll-supply = <_reg>;
+   ddc = <_ddc>;
+   status = "okay";
+   };
+
+   hdmi_ddc: i2c at 1388 {
+   status = "okay";
+   pinctrl-names = "default";
+   pinctrl-0 = <_bus>;
+   };
+
+   i2c at 138E {
+   status = "okay";
+   };
 };

 _1 {
@@ -339,4 +386,9 @@
samsung,pins = "gpx1-3";
samsung,pin-pud = <0>;
};
+
+   hdmi_hpd: hdmi-hpd {
+   samsung,pins = "gpx3-7";
+   samsung,pin-pud = <1>;
+   };
 };
-- 
1.9.2

[PATCH 5/7] ARM: dts: exynos4: add hdmi related nodes

[Marek Szyprowski]

This patch adds entries for HDMI, Mixer and i2c with hdmi-phy modules
found in Exynos 4210 and 4x12 SoCs.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos4.dtsi| 37 +
 arch/arm/boot/dts/exynos4210.dtsi |  5 +
 arch/arm/boot/dts/exynos4x12.dtsi | 10 ++
 3 files changed, 52 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 933bd2141601..5b55c4de7e6f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -38,6 +38,7 @@
i2c5 = _5;
i2c6 = _6;
i2c7 = _7;
+   i2c8 = _8;
csis0 = _0;
csis1 = _1;
fimc0 = _0;
@@ -527,6 +528,22 @@
status = "disabled";
};

+   i2c_8: i2c at 138E {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "samsung,s3c2440-hdmiphy-i2c";
+   reg = <0x138E 0x100>;
+   interrupts = <0 93 0>;
+   clocks = < CLK_I2C_HDMI>;
+   clock-names = "i2c";
+   status = "disabled";
+
+   hdmi_i2c_phy: hdmiphy at 38 {
+   compatible = "exynos4210-hdmiphy";
+   reg = <0x38>;
+   };
+   };
+
spi_0: spi at 1392 {
compatible = "samsung,exynos4210-spi";
reg = <0x1392 0x100>;
@@ -634,4 +651,24 @@
samsung,power-domain = <_lcd0>;
status = "disabled";
};
+
+   hdmi: hdmi at 12D0 {
+   compatible = "samsung,exynos4210-hdmi";
+   reg = <0x12D0 0x7>;
+   interrupts = <0 92 0>;
+   clock-names = "hdmi", "sclk_hdmi", "sclk_pixel", 
"sclk_hdmiphy", "mout_hdmi";
+   clocks = < CLK_HDMI>, < CLK_SCLK_HDMI>, < 
CLK_SCLK_PIXEL>, < CLK_SCLK_HDMIPHY>, < CLK_MOUT_HDMI>;
+   phy = <_i2c_phy>;
+   samsung,power-domain = <_tv>;
+   samsung,syscon-phandle = <_system_controller>;
+   status = "disabled";
+   };
+
+   mixer: mixer at 12C1 {
+   compatible = "samsung,exynos4210-mixer";
+   interrupts = <0 91 0>;
+   reg = <0x12C1 0x2100>, <0x12c0 0x300>;
+   samsung,power-domain = <_tv>;
+   status = "disabled";
+   };
 };
diff --git a/arch/arm/boot/dts/exynos4210.dtsi 
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f38821..d32063d00ad7 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -171,4 +171,9 @@
samsung,lcd-wb;
};
};
+
+   mixer: mixer at 12C1 {
+   clock-names = "mixer", "sclk_hdmi", "vp", "mout_mixer", 
"sclk_mixer";
+   clocks = < CLK_MIXER>, < CLK_SCLK_HDMI>, < 
CLK_VP>, < CLK_MOUT_MIXER>, < CLK_SCLK_MIXER>;
+   };
 };
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index c5a943df1cd7..856cd45b696b 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -270,4 +270,14 @@
compatible = "samsung,exynos4x12-usb2-phy";
samsung,sysreg-phandle = <_reg>;
};
+
+   hdmi: hdmi at 12D0 {
+   compatible = "samsung,exynos4212-hdmi";
+   };
+
+   mixer: mixer at 12C1 {
+   compatible = "samsung,exynos4212-mixer";
+   clock-names = "mixer", "sclk_hdmi", "vp";
+   clocks = < CLK_MIXER>, < CLK_SCLK_HDMI>, < 
CLK_VP>;
+   };
 };
-- 
1.9.2

[PATCH 4/7] Exynos: add support for 'domain-always-on' property

[Marek Szyprowski]

This patch adds support for domain-always-on property to Exynos power
domain driver. Domains with this property as always kept enabled.

Signed-off-by: Marek Szyprowski 
---
 Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 2 ++
 arch/arm/mach-exynos/pm_domains.c | 6 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 5216b419016a..b25d9b1ce471 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -8,6 +8,8 @@ Required Properties:
 * samsung,exynos4210-pd - for exynos4210 type power domain.
 - reg: physical base address of the controller and length of memory mapped
 region.
+Optional properties:
+- domain-always-on:keeps the domain always enabled

 Node of a device using power domains must have a samsung,power-domain property
 defined with a phandle to respective power domain.
diff --git a/arch/arm/mach-exynos/pm_domains.c 
b/arch/arm/mach-exynos/pm_domains.c
index fe6570ebbdde..279b008de02f 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -151,6 +151,7 @@ static __init int exynos4_pm_init_power_domain(void)
struct device_node *np;

for_each_compatible_node(np, NULL, "samsung,exynos4210-pd") {
+   struct dev_power_governor *gov = NULL;
struct exynos_pm_domain *pd;
int on;

@@ -163,6 +164,9 @@ static __init int exynos4_pm_init_power_domain(void)
return -ENOMEM;
}

+   if (of_property_read_bool(np, "domain-always-on"))
+   gov = _domain_always_on_gov;
+
pd->pd.name = kstrdup(np->name, GFP_KERNEL);
pd->name = pd->pd.name;
pd->base = of_iomap(np, 0);
@@ -174,7 +178,7 @@ static __init int exynos4_pm_init_power_domain(void)

on = __raw_readl(pd->base + 0x4) & S5P_INT_LOCAL_PWR_EN;

-   pm_genpd_init(>pd, NULL, !on);
+   pm_genpd_init(>pd, gov, !on);
}

bus_register_notifier(_bus_type, _nb);
-- 
1.9.2

[PATCH 3/7] drm: hdmi/mixer: enable exynos 4210 and 4x12 soc support

[Marek Szyprowski]

Configuration sets for Exynos 4210 and 4x12 SoC were already defined in
Exynos HDMI and Mixed drivers, but they lacked proper linking to device
tree 'compatible' values. This patch fixes this issue adding support for
following compatible values: samsung,exynos4210-mixer,
samsung,exynos4212-mixer and samsung,exynos4210-hdmi. It also corrects
access to sclk_mixer clock, which is available only on Exynos 4210.

Signed-off-by: Marek Szyprowski 
---
 .../devicetree/bindings/video/exynos_mixer.txt |  5 ++-
 drivers/gpu/drm/exynos/exynos_hdmi.c   | 10 +
 drivers/gpu/drm/exynos/exynos_mixer.c  | 51 +++---
 3 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt 
b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 7bfde9c9d658..08b394b1edbf 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -4,8 +4,9 @@ Required properties:
 - compatible: value should be one of the following:
1) "samsung,exynos5-mixer" 
2) "samsung,exynos4210-mixer"
-   3) "samsung,exynos5250-mixer"
-   4) "samsung,exynos5420-mixer"
+   3) "samsung,exynos4212-mixer"
+   4) "samsung,exynos5250-mixer"
+   5) "samsung,exynos5420-mixer"

 - reg: physical base address of the mixer and length of memory mapped
region.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a9a87d024c56..7bd99939b984 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -593,6 +593,13 @@ static struct hdmi_driver_data exynos4212_hdmi_driver_data 
= {
.is_apb_phy = 0,
 };

+static struct hdmi_driver_data exynos4210_hdmi_driver_data = {
+   .type   = HDMI_TYPE13,
+   .phy_confs  = hdmiphy_v13_configs,
+   .phy_conf_count = ARRAY_SIZE(hdmiphy_v13_configs),
+   .is_apb_phy = 0,
+};
+
 static struct hdmi_driver_data exynos5_hdmi_driver_data = {
.type   = HDMI_TYPE14,
.phy_confs  = hdmiphy_v13_configs,
@@ -2277,6 +2284,9 @@ static struct of_device_id hdmi_match_types[] = {
.compatible = "samsung,exynos5-hdmi",
.data = _hdmi_driver_data,
}, {
+   .compatible = "samsung,exynos4210-hdmi",
+   .data = _hdmi_driver_data,
+   }, {
.compatible = "samsung,exynos4212-hdmi",
.data = _hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 7529946d0a74..9d0c21a50a86 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -76,7 +76,7 @@ struct mixer_resources {
struct clk  *vp;
struct clk  *sclk_mixer;
struct clk  *sclk_hdmi;
-   struct clk  *sclk_dac;
+   struct clk  *mout_mixer;
 };

 enum mixer_version_id {
@@ -93,6 +93,7 @@ struct mixer_context {
boolinterlace;
boolpowered;
boolvp_enabled;
+   boolhas_sclk;
u32 int_en;

struct mutexmixer_mutex;
@@ -106,6 +107,7 @@ struct mixer_context {
 struct mixer_drv_data {
enum mixer_version_id   version;
boolis_vp_enabled;
+   boolhas_sclk;
 };

 static const u8 filter_y_horiz_tap8[] = {
@@ -809,19 +811,23 @@ static int vp_resources_init(struct mixer_context 
*mixer_ctx)
dev_err(dev, "failed to get clock 'vp'\n");
return -ENODEV;
}
-   mixer_res->sclk_mixer = devm_clk_get(dev, "sclk_mixer");
-   if (IS_ERR(mixer_res->sclk_mixer)) {
-   dev_err(dev, "failed to get clock 'sclk_mixer'\n");
-   return -ENODEV;
-   }
-   mixer_res->sclk_dac = devm_clk_get(dev, "sclk_dac");
-   if (IS_ERR(mixer_res->sclk_dac)) {
-   dev_err(dev, "failed to get clock 'sclk_dac'\n");
-   return -ENODEV;
-   }

-   if (mixer_res->sclk_hdmi)
-   clk_set_parent(mixer_res->sclk_mixer, mixer_res->sclk_hdmi);
+   if (mixer_ctx->has_sclk) {
+   mixer_res->sclk_mixer = devm_clk_get(dev, "sclk_mixer");
+   if (IS_ERR(mixer_res->sclk_mixer)) {
+   dev_err(dev, "failed to get clock 'sclk_mixer'\n");
+   return -ENODEV;
+   }
+   mixer_res->mout_mixer = devm_clk_get(dev, "mout_mixer");
+   if (IS_ERR(mixer_res->mout_mixer)) {
+   dev_err(dev, "failed to get clock 'mout_mixer'\n");
+   return -ENODEV;
+   }
+
+   if (mixer_res->sclk_hdmi && 

[PATCH 2/7] drm: exynos: hdmi: make 'hdmi-en' regulator optional and keep it enabled

[Marek Szyprowski]

HDMI_EN regulator is additional regulator for providing voltage source
for DCC lines available on HDMI connector. When there is no power
provided for DDC epprom, some TV-sets do not pulls up HPD (hot plug
detect) line, what causes HDMI block to stay turned off. This patch
enables HDMI_EN regulator (if available) on driver probe and keep it
enabled all the time to let TV-set correctly signal HPD event.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index aa259b0a873a..a9a87d024c56 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -84,6 +84,7 @@ struct hdmi_resources {
struct clk  *sclk_hdmiphy;
struct clk  *mout_hdmi;
struct regulator_bulk_data  *regul_bulk;
+   struct regulator*reg_hdmi_en;
int regul_count;
 };

@@ -2168,7 +2169,6 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
struct device *dev = hdata->dev;
struct hdmi_resources *res = >res;
static char *supply[] = {
-   "hdmi-en",
"vdd",
"vdd_osc",
"vdd_pll",
@@ -2228,6 +2228,20 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
}
res->regul_count = ARRAY_SIZE(supply);

+   res->reg_hdmi_en = devm_regulator_get(dev, "hdmi-en");
+   if (IS_ERR(res->reg_hdmi_en) && PTR_ERR(res->reg_hdmi_en) != -ENOENT) {
+   DRM_ERROR("failed to get hdmi-en regulator\n");
+   return PTR_ERR(res->reg_hdmi_en);
+   }
+   if (!IS_ERR(res->reg_hdmi_en)) {
+   ret = regulator_enable(res->reg_hdmi_en);
+   if (ret) {
+   DRM_ERROR("failed to enable hdmi-en regulator\n");
+   return ret;
+   }
+   } else
+   res->reg_hdmi_en = NULL;
+
return ret;
 fail:
DRM_ERROR("HDMI resource init - failed\n");
@@ -2494,6 +2508,9 @@ static int hdmi_remove(struct platform_device *pdev)

cancel_delayed_work_sync(>hotplug_work);

+   if (hdata->res.reg_hdmi_en)
+   regulator_disable(hdata->res.reg_hdmi_en);
+
put_device(>hdmiphy_port->dev);
put_device(>ddc_adpt->dev);

-- 
1.9.2

[PATCH 1/7] clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks

[Marek Szyprowski]

This patch adds support for exporting mout_hdmi and mout_mixer to device
tree. Access to those clocks is required to correctly setup HDMI module
on Exynos 4210 and 4x12 SoCs.

Signed-off-by: Marek Szyprowski 
CC: Mike Turquette 
CC: Tomasz Figa 
---
 drivers/clk/samsung/clk-exynos4.c   | 4 ++--
 include/dt-bindings/clock/exynos4.h | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index 4f150c9dd38c..a30a779869eb 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -440,7 +440,7 @@ static struct samsung_fixed_rate_clock 
exynos4210_fixed_rate_clks[] __initdata =
 static struct samsung_mux_clock exynos4_mux_clks[] __initdata = {
MUX_FA(CLK_MOUT_APLL, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
CLK_SET_RATE_PARENT, 0, "mout_apll"),
-   MUX(0, "mout_hdmi", mout_hdmi_p, SRC_TV, 0, 1),
+   MUX(CLK_MOUT_HDMI, "mout_hdmi", mout_hdmi_p, SRC_TV, 0, 1),
MUX(0, "mout_mfc1", sclk_evpll_p, SRC_MFC, 4, 1),
MUX(0, "mout_mfc", mout_mfc_p, SRC_MFC, 8, 1),
MUX_F(CLK_MOUT_G3D1, "mout_g3d1", sclk_evpll_p, SRC_G3D, 4, 1,
@@ -463,7 +463,7 @@ static struct samsung_mux_clock exynos4210_mux_clks[] 
__initdata = {
MUX(0, "mout_aclk100", sclk_ampll_p4210, SRC_TOP0, 16, 1),
MUX(0, "mout_aclk160", sclk_ampll_p4210, SRC_TOP0, 20, 1),
MUX(0, "mout_aclk133", sclk_ampll_p4210, SRC_TOP0, 24, 1),
-   MUX(0, "mout_mixer", mout_mixer_p4210, SRC_TV, 4, 1),
+   MUX(CLK_MOUT_MIXER, "mout_mixer", mout_mixer_p4210, SRC_TV, 4, 1),
MUX(0, "mout_dac", mout_dac_p4210, SRC_TV, 8, 1),
MUX(0, "mout_g2d0", sclk_ampll_p4210, E4210_SRC_IMAGE, 0, 1),
MUX(0, "mout_g2d1", sclk_evpll_p, E4210_SRC_IMAGE, 4, 1),
diff --git a/include/dt-bindings/clock/exynos4.h 
b/include/dt-bindings/clock/exynos4.h
index 1106ca540a96..5bfb3509ee3c 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -229,6 +229,8 @@
 #define CLK_MOUT_G3D1  393
 #define CLK_MOUT_G3D   394
 #define CLK_ACLK400_MCUISP 395 /* Exynos4x12 only */
+#define CLK_MOUT_HDMI  396
+#define CLK_MOUT_MIXER 397

 /* div clocks */
 #define CLK_DIV_ISP0   450 /* Exynos4x12 only */
-- 
1.9.2

[PATCH 0/7] Exynos4: enable HDMI support for Odroid and UniversalC210

[Marek Szyprowski]

Hello,

This is a long awaited patch series enabling support for HDMI output
available on Exynos4412-based Odroid boards (X/X2/U2/U3/U3+) and
Exynos4210 Universal C210 board.

This patch consists of 3 groups of patches, which are aimed to be merged
to respective maintainer kernel trees.

First patch ("clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER
clocks") adds missing device tree support for hdmi related clocks. It is
prepared for clk kernel tree.

Next two patches ("drm: exynos: hdmi: make 'hdmi-en' regulator optional
and keep it enabled" and "drm: hdmi/mixer: enable exynos 4210 and 4x12
soc support") add proper support for Exynos4 SoCs to Exynos DRM drivers.
Those patches should go to exynos-drm kernel tree.

Last patches ("Exynos: add support for 'domain-always-on' property",
"ARM: dts: exynos4: add hdmi related nodes", "ARM: dts:
exynos4412-odroid: enable hdmi support" and "ARM: dts:
exynos4210-universal_c210: enable hdmi support") adds changes to all DTS
files and adds 'domain-always-on' property to Exynos power-domain
driver. This property is needed to resolve the non-trivial dependences
between TV and LCD0 power domains and the power on/off sequence of the
TV and mixer modules.

Patches are prepared on top of v3.16-rc3 with '[PATCH v2 0/4] Add
Exynos4412 based Odroid X2 and U2/U3/U3+ support' series and '[PATCH]
ARM: dts: exynos4412-odroid: add support for GPIO buttons' patch
applied:
http://www.spinics.net/lists/linux-samsung-soc/msg33115.html
http://www.spinics.net/lists/linux-samsung-soc/msg33497.html

Kernel tree with all Odroid related patches is available at
http://git.linaro.org/git-ro/people/marek.szyprowski/linux-srpol.git
on v3.16-odroid branch.

Best regards
Marek Szyprowski
Samsung R Institute Poland

Marek Szyprowski (6):
  clk: exynos4: add support for MOUT_HDMI and MOUT_MIXER clocks
  drm: exynos: hdmi: make 'hdmi-en' regulator optional and keep it
enabled
  drm: hdmi/mixer: enable exynos 4210 and 4x12 soc support
  Exynos: add support for 'domain-always-on' property
  ARM: dts: exynos4: add hdmi related nodes
  ARM: dts: exynos4412-odroid: enable hdmi support

Tomasz Stanislawski (1):
  ARM: dts: exynos4210-universal_c210: enable hdmi support

 .../bindings/arm/exynos/power_domain.txt   |  2 +
 .../devicetree/bindings/video/exynos_mixer.txt |  5 +-
 arch/arm/boot/dts/exynos4.dtsi | 37 
 arch/arm/boot/dts/exynos4210-universal_c210.dts| 65 ++
 arch/arm/boot/dts/exynos4210.dtsi  |  5 ++
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 52 +
 arch/arm/boot/dts/exynos4x12.dtsi  | 10 
 arch/arm/mach-exynos/pm_domains.c  |  6 +-
 drivers/clk/samsung/clk-exynos4.c  |  4 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   | 29 +-
 drivers/gpu/drm/exynos/exynos_mixer.c  | 51 -
 include/dt-bindings/clock/exynos4.h|  2 +
 12 files changed, 247 insertions(+), 21 deletions(-)

-- 
1.9.2

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

[Chen, Tiejun]

On 2014/6/30 19:18, Michael S. Tsirkin wrote:
> On Thu, Jun 19, 2014 at 05:53:51PM +0800, Tiejun Chen wrote:
>> Originally the reason to probe ISA bridge instead of Dev31:Fun0
>> is to make graphics device passthrough work easy for VMM, that
>> only need to expose ISA bridge to let driver know the real
>> hardware underneath. This is a requirement from virtualization
>> team. Especially in that virtualized environments, XEN, there
>> is irrelevant ISA bridge in the system with that legacy qemu
>> version specific to xen, qemu-xen-traditional. So to work
>> reliably, we should scan through all the ISA bridge devices
>> and check for the first match, instead of only checking the
>> first one.
>>
>> But actually, qemu-xen-traditional, is always enumerated with
>> Dev31:Fun0, 00:1f.0 as follows:
>>
>> hw/pt-graphics.c:
>>
>> intel_pch_init()
>>  |
>>  + pci_isa_bridge_init(bus, PCI_DEVFN(0x1f, 0), ...);
>>
>> so this mean that isa bridge is still represented with Dev31:Func0
>> like the native OS. Furthermore, currently we're pushing VGA
>> passthrough support into qemu upstream, and with some discussion,
>> we wouldn't set the bridge class type and just expose this devfn.
>>
>> So we just go back to check devfn to make life normal.
>>
>> Signed-off-by: Tiejun Chen 
>> ---
>>   drivers/gpu/drm/i915/i915_drv.c | 19 +++
>>   1 file changed, 3 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 651e65e..cb2526e 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -417,18 +417,8 @@ void intel_detect_pch(struct drm_device *dev)
>>  return;
>>  }
>>
>> -/*
>> - * The reason to probe ISA bridge instead of Dev31:Fun0 is to
>> - * make graphics device passthrough work easy for VMM, that only
>> - * need to expose ISA bridge to let driver know the real hardware
>> - * underneath. This is a requirement from virtualization team.
>> - *
>> - * In some virtualized environments (e.g. XEN), there is irrelevant
>> - * ISA bridge in the system. To work reliably, we should scan trhough
>> - * all the ISA bridge devices and check for the first match, instead
>> - * of only checking the first one.
>> - */
>> -while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
>> +pch = pci_get_bus_and_slot(0, PCI_DEVFN(0x1f, 0));
>> +if (pch) {
>
> Then if you want to use this slot for something else, what happens?

I think this slot is always occupied to be dedicated to this ISA bridge 
in the platform.

So don't worry, the drivers in Linux and Windows can live with this.

Thanks
Tiejun

> If you want to relax the PCI_CLASS_BRIDGE_ISA requirement when
> running on top of a hypervisor, just scan all devices.
>
>>  if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>>  unsigned short id = pch->device & 
>> INTEL_PCH_DEVICE_ID_MASK;
>>  dev_priv->pch_id = id;
>> @@ -462,10 +452,7 @@ void intel_detect_pch(struct drm_device *dev)
>>  DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
>>  WARN_ON(!IS_HASWELL(dev));
>>  WARN_ON(!IS_ULT(dev));
>> -} else
>> -continue;
>> -
>> -break;
>> +}
>>  }
>>  }
>>  if (!pch)
>> --
>> 1.9.1
>>
>

[PATCH 5/5] drm/i915: Kick out vga console

[Ed Tomlinson]

Hi Chris,

I had to rediff to get a patch that applies...  I am not hanging with this 
applied - it
does look like the i915 is starting is initialization later boot the new kernel.

[2.389796] [drm] Radeon Display Connectors
[2.389798] [drm] Connector 0:
[2.389799] [drm]   DP-1
[2.389799] [drm]   HPD2
[2.389801] [drm]   DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 
0x653c
[2.389802] [drm]   Encoders:
[2.389803] [drm] DFP1: INTERNAL_UNIPHY2
[2.389804] [drm] Connector 1:
[2.389805] [drm]   HDMI-A-1
[2.389805] [drm]   HPD3
[2.389806] [drm]   DDC: 0x6550 0x6550 0x6554 0x6554 0x6558 0x6558 0x655c 
0x655c
[2.389807] [drm]   Encoders:
[2.389808] [drm] DFP2: INTERNAL_UNIPHY2
[2.389809] [drm] Connector 2:
[2.389810] [drm]   DVI-D-1
[2.389811] [drm]   HPD1
[2.389812] [drm]   DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 
0x656c
[2.389813] [drm]   Encoders:
[2.389814] [drm] DFP3: INTERNAL_UNIPHY1
[2.389815] [drm] Connector 3:
[2.389815] [drm]   DVI-I-1
[2.389816] [drm]   HPD6
[2.389817] [drm]   DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 
0x658c
[2.389818] [drm]   Encoders:
[2.389819] [drm] DFP4: INTERNAL_UNIPHY
[2.389820] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[2.435689] raid6: avx2x2   24564 MB/s
[2.435691] Switched to clocksource tsc
[2.489087] usb 1-8: new low-speed USB device number 7 using xhci_hcd
[2.492403] raid6: avx2x4   34887 MB/s
[2.492404] raid6: using algorithm avx2x4 (34887 MB/s)
[2.492405] raid6: using avx2x2 recovery algorithm
[2.492789] xor: automatically using best checksumming function:
[2.502557] Adding 5779452k swap on /dev/sdb2.  Priority:-2 extents:1 
across:5779452k FS
[2.511532] [drm] fb mappable at 0xE098E000
[2.511536] [drm] vram apper at 0xE000
[2.511538] [drm] size 9216000
[2.511539] [drm] fb depth is 24
[2.511541] [drm]pitch is 7680
[2.511590] fbcon: radeondrmfb (fb0) is primary device
[2.516691] nct6775: Found NCT6776D/F or compatible chip at 0x2e:0x290
[2.525778]avx   : 41474.400 MB/sec
[2.532408] Console: switching to colour frame buffer device 240x75
[2.535567] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[2.535567] radeon :01:00.0: registered panic notifier
[2.544968] Btrfs loaded
[2.545276] BTRFS: device fsid 9d4254aa-6715-4fa8-986a-1af0d51768ad devid 1 
transid 308068 /dev/sdc1
[2.545739] BTRFS: device fsid 9d4254aa-6715-4fa8-986a-1af0d51768ad devid 2 
transid 308068 /dev/sdb1
[2.552946] [drm] Initialized radeon 2.39.0 20080528 for :01:00.0 on 
minor 0
[2.553248] [drm] Memory usable by graphics device = 2048M
[2.553273] [drm] Replacing VGA console driver
[2.572539] i915 :00:02.0: irq 46 for MSI/MSI-X
[2.572546] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.572565] [drm] Driver supports precise vblank timestamp query.

If you are happy with this you can give this patch my tested by.

Thanks
Ed Tomlinson

On Monday 30 June 2014 07:59:55 Chris Wilson wrote:
> On Sat, Jun 28, 2014 at 11:55:19PM -0400, Ed Tomlinson wrote:
> > On Saturday 28 June 2014 15:28:22 Ed Tomlinson wrote:
> > 
> > Resend without html krud which causes list to bounce the message.
> > 
> > > Hi
> > > 
> > > This commit ( a4de05268e674e8ed31df6348269e22d6c6a1803 ) hangs my boot 
> > > with 3.16-git.  Reverting it lets the boot proceed. 
> > > 
> > > I have an i7 with a built-in i915 and an pcie r7 260x.  The R7 is the 
> > > primary console.  The i915 is initialized
> > > but does not have a physical display attached.
> > > 
> > > With the patch applied the boot stops at the messages:
> > > 
> > > [drm] Memory usable by graphics device = 2048M
> > > [drm] Replacing VGA console driver
> 
> The issue looks like that we are ripping out the radeon fb_con whilst it
> is active and that upsets everyone. In which case, I think the
> compromise is:
> 
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5f44581..4915f1d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1439,18 +1439,20 @@ static int i915_kick_out_vgacon(struct 
> drm_i915_private *dev_priv)
>  #else
>  static int i915_kick_out_vgacon(struct drm_i915_private *dev_priv)
>  {
> -   int ret;
> +   int ret = 0;
>  
> DRM_INFO("Replacing VGA console driver\n");
>  
> console_lock();
> -   ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 1);
> -   if (ret == 0) {
> -   ret = do_unregister_con_driver(_con);
> -
> -   /* Ignore "already unregistered". */
> -   if (ret == -ENODEV)
> -   ret = 0;
> +   if (con_is_bound(_con)) {
> +   ret = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 
> 1, 1);
> +   if (ret == 0) {
> +   ret = 

[PATCH V3 1/7] drm/exynos: Support DP CLKCON register in FIMD driver

[Inki Dae]

2014-06-30 14:31 GMT+09:00 Andrzej Hajda :
> On 06/30/2014 03:14 AM, Jingoo Han wrote:
>> On Friday, June 27, 2014 10:03 PM, Ajay kumar wrote:
>>> On Fri, Jun 27, 2014 at 6:14 PM, Andrzej Hajda  
>>> wrote:
 On 06/27/2014 01:48 PM, Ajay kumar wrote:
> On Fri, Jun 27, 2014 at 4:52 PM, Andrzej Hajda  
> wrote:
>> +CC DT
>>
>> On 06/27/2014 12:12 PM, Ajay Kumar wrote:
>>> Add the missing setting for DP CLKCON register.
>>>
>>> This register is present on Exynos5 based FIMD controllers,
>>> and needs to be set if we are using DP.
>>>
>>> Signed-off-by: Ajay Kumar 
>>> ---
>>>  .../devicetree/bindings/video/samsung-fimd.txt |1 +
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   23 
>>> 
>>>  include/video/samsung_fimd.h   |4 
>>>  3 files changed, 28 insertions(+)
>> [.]
>>
>>>  static const struct of_device_id fimd_driver_dt_match[] = {
>>> @@ -331,6 +341,10 @@ static void fimd_commit(struct exynos_drm_manager 
>>> *mgr)
>>>   if (clkdiv > 1)
>>>   val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
>>>
>>> + if (ctx->driver_data->has_dp_clkcon &&
>>> + ctx->exynos_fimd_output_type == EXYNOS_FIMD_OUTPUT_DP)
>>> + writel(DP_CLK_ENABLE, ctx->regs + DP_CLKCON);
>>> +
>>>   writel(val, ctx->regs + VIDCON0);
 New code should not split VIDCON0 related code.It should be moved few
 lines above or few lines below.
>>> Ok, for better readability.
>>>
 Anyway this code should be rather placed in power related functions of
 dp encoder, as it enables dp. The only question
 is if DP_CLKCON update can be performed after VIDCON0 update. If yes the
 solution of the whole problem
>>> I will check this.
>>>
 seems to be simple:
 - fimd should provide function fimd_set_dp_clk_gate or sth similar,
 - this function should be called in exynos_dp_poweron/exynos_dp_poweroff.
 I hope I have not missed anything this time.
>>> But, it won't look good to export a FIMD function which sets a FIMD 
>>> register,
>>> and call it in DP driver!
>>> What does Inki/Jingoo have to say about this?
>> I agree with Ajay Kumar's opinion.
>> It doesn't look good to export the function to set FIMD register
>> and call it by DP driver.
>
> DP_CLKCON HW register shows clearly there is direct hardware dependency
> between DP and FIMD.
> Reflecting this dependency in drivers is just a consequence of HW design.

Right, and I cannot understand why mDNIe and DP clock enable bit
exists in FIMD ip. :(

> Moreover the register gates also clock for MDNIE, this solution can be
> used there as well.
>
> Anyway the most important is that we should avoid adding DT bindings for
> things we can evaluate in drivers.
>

It wouldn't be best way only to avoid adding DT binding. DT binding
could be good way to handle complicated hardware pipelines if needed.
Of course, if driver can handle it simply, it would be better to avoid
adding DT binding. However, Exynos SoC are complicated.

Exynos SoC have more IPs to should be considered; SMIES, mDNIe and MIE
as image enhancement devices, and eDP, MIPI-DSI, and DPI (FIMD
connected to panel directly) as Display bus devices and parallel panel
device. And image enhancement device and Display bus device can be
used together.

FIMD  Panel
FIMD  Display bus device  Panel
FIMD  image enhancement device  Panel
FIMD  image enhancement device  FIMD-Lite  Panel
FIMD  image enhancement device  Display bus device
 Panel
FIMD  image enhancement device  FIMD-Lite 
Display bus device  Panel

And Display bus devices and parallel device couldn't be switched in
runtime since kernel has been booted. However, image enhancement
devices can be enabled or disabled in runtime so the output path of
FIMD can be changed to another path dynamically - actually, I had
handled such scenarios. So if Exynos drm driver should be considered
for above all cases, it'd make Eyxnos drm driver too complicated.

If DT people and other SoC maintainers give us your opinions, it would
be helpful for us. I will look into other SoC how they are handling
similar cases.

Thanks,
Inki Dae

> Regards
> Andrzej
>
>>
>> Best regards,
>> Jingoo Han
>>> Regards,
>>> Ajay
>>>
>> []
>>
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 70409] Discrete GPU fails to initialize and X segfaults on dual-GPU r600/radeonsi laptop

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

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

--- Comment #11 from Michel D?nzer  ---
(In reply to comment #9)
> But I get black picture when I'm trying to run DRI_PRIME=1 glxgears...

PRIME currently requires a compositing manager to work.

> I understand it's not related to this bug, [...]

Indeed, please take your remaining issues elsewhere.

-- 
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/20140701/583ec144/attachment.html>

[Bug 68571] GPU lockup on AMD Radeon HD6850 with DPM=1

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

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

Dieter N?tzel  changed:

   What|Removed |Added

 CC||Dieter at nuetzel-hh.de

--- Comment #50 from Dieter N?tzel  ---
(In reply to perry3d from comment #49)
> Can not confirm. X stills freezes with latest kernel from git.
> 
> Another hint: radeon.audio=0 and blacklisting the snd_intel_hda modules are
> not the same. If i remove the modules the problem disappears, but i still
> get the freezes with radeon.audio=0.

Your card is ni (Northern Island)?
Please try this patch on 3.14/.3.15/3.16-rc2/-rc3.
https://bugzilla.kernel.org/show_bug.cgi?id=79071#c4

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