[PULL] topic/core-stuff for 3.18

Hi Dave, So small drm stuff all over for 3.18. Biggest one is the cmdline parsing from Chris with a few fixes from me to make it work for stupid kernel configs. Plus the atomic prep series. Tested for more than a week in -nightly and Ville/Imre indeed discovered some fun which is now fixed (and

[PULL] first drm-intel-next for 3.18

Hi Dave, So you made noises that you wanted to open drm-next right after -rc1, so I've figured I'll test this ;-) drm-intel-next-2014-08-08: - Setting dp M2/N2 values plus state checker support (Vandana Kannan) - chv power well support (Ville) - DP training pattern 3 support for chv (Ville) - cle

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

> I'd rather not have a sysfs entry. I'd prefer a mesa env var or drirc > option to force the CS flag. Yeah, that actually sounds like a good idea. I think we could add a new dword to the flags chunk for this, or use the priority field which is unused for UVD on those older chipsets anyway. If

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

Am 15.08.2014 um 17:32 schrieb Grigori Goronzy: > On 15.08.2014 17:26, Alex Deucher wrote: >> On Fri, Aug 15, 2014 at 11:20 AM, Grigori Goronzy >> wrote: >>> On 15.08.2014 16:11, Christian K?nig wrote: Hi Marco, the problem with an CS ioctl flag is that we sometimes don't know how

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

== handle) > >>>> { > >>>> + > >>>> > radeon_uvd_fps_note_event(p->rdev, i); > >>>> > return 0; > >>>> + } > >>>> } > >>>> > >>>> /* handle not found > >>>> try to alloc a new one */ > >>>> @@ -428,6 +475,7 @@ static int > >>>> radeon_uvd_cs_msg(struct > >>>> radeon_cs_parser > >>>> *p, struct radeon_bo *bo, > >>>> if > >>>> > (!atomic_cmpxchg(&p->rdev->uvd.handles[i], > >>>> 0, > >>>> handle)) { > >>>> > >>>> p->rdev->uvd.filp[i] = p->filp; > >>>> > >>>> p->rdev->uvd.img_size[i] = > img_size; > >>>> + > >>>> > radeon_uvd_fps_clear_events(p->rdev, > >>>> i); > >>>> > return 0; > >>>> } > >>>> } > >>>> @@ -763,7 +811,7 @@ int > >>>> > radeon_uvd_get_destroy_msg(struct > >>>> radeon_device > >>>> *rdev, int ring, > >>>> static void > >>>> radeon_uvd_count_handles(struct > >>>> radeon_device *rdev, > >>>> > >>>>unsigned *sd, > unsigned *hd) > >>>> { > >>>> - unsigned i; > >>>> + unsigned i, > fps_rate = 0; > >>>> > >>>> *sd = 0; > >>>> *hd = 0; > >>>> @@ -772,10 +820,13 @@ > static void > >>>> radeon_uvd_count_handles(struct > >>>> radeon_device *rdev, > >>>> if > >>>> > (!atomic_read(&rdev->uvd.handles[i])) > >>>> > continue; > >>>> > >>>> - if > >>>> (rdev->uvd.img_size[i] >= > 720*576) > >>>> - > ++(*hd); > >>>> - else > >>>> - > ++(*sd); > >>>> + fps_rate = > >>>> > radeon_uvd_estimate_fps(rdev, i); > >>>> + > >>>> + if > >>>> (rdev->uvd.img_size[i] >= > 720*576) { > >>>> + > (*hd) += > >>>> fps_rate > 30 ? 1 : 2; > >>>> + } else { > >>>> + > (*sd) += > >>>> fps_rate > 30 ? 1 : 2; > >>>> + } > >>>> } > >>>> } > >>>> > >>>> @@ -805,6 +856,7 @@ void > >>>> radeon_uvd_note_usage(struct > >>>> radeon_device > >>>> *rdev) > >>>> set_clocks &= > >>>> > schedule_delayed_work(&rdev->uvd.idle_work, > >>>> > >>>> > msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); > >>>> > >>>> + > >>>> if > >>>> ((rdev->pm.pm_method == > >>>> PM_METHOD_DPM) && > >>>> rdev->pm.dpm_enabled) { > >>>> > unsigned hd = > >>>> 0, sd = 0; > >>>> > >>>> radeon_uvd_count_handles(rdev, > >>>> &sd, &hd); > >>>> -- > >>>> 1.9.1 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Marco Antonio Benatto > >>>> Linux user ID:#506236 > >>> > >> > >> > > > > > > -- > Marco Antonio Benatto > Linux user ID:#506236 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/68d9afe1/attachment-0001.sig>

Fwd: Re: [PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

@@ -419,8 +464,10 @@ static int >>>>>> radeon_uvd_cs_msg(struct >>>>>> radeon_cs_parser >>>>>> *p, struct radeon_bo *bo

[Bug 82671] New: [r600g-evergreen][compute]Empty kernel execution causes crash

t was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/15c01a9c/attachment.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

radeon_cs_parser >>>> *p, struct radeon_bo *bo, >>>> if >>>> >>>> (!atomic_cmpxchg(&p->rdev->uvd.handles[i], >>>> 0, >>>> handle)) { >>>> >>>> p->rdev->uvd.filp[i] = p->filp; >>>> >>>> p->rdev->uvd.img_size[i] = img_size; >>>> + >>>> radeon_uvd_fps_clear_events(p->rdev, >>>> i); >>>> return 0; >>>> } >>>> } >>>> @@ -763,7 +811,7 @@ int >>>> radeon_uvd_get_destroy_msg(struct >>>> radeon_device >>>> *rdev, int ring, >>>> static void >>>> radeon_uvd_count_handles(struct >>>> radeon_device *rdev, >>>> >>>>unsigned *sd, unsigned *hd) >>>> { >>>> - unsigned i; >>>> + unsigned i, fps_rate = 0; >>>> >>>> *sd = 0; >>>> *hd = 0; >>>> @@ -772,10 +820,13 @@ static void >>>> radeon_uvd_count_handles(struct >>>> radeon_device *rdev, >>>> if >>>> (!atomic_read(&rdev->uvd.handles[i])) >>>> continue; >>>> >>>> - if >>>> (rdev->uvd.img_size[i] >= 720*576) >>>> - ++(*hd); >>>> - else >>>> - ++(*sd); >>>> + fps_rate = >>>> radeon_uvd_estimate_fps(rdev, i); >>>> + >>>> + if >>>> (rdev->uvd.img_size[i] >= 720*576) { >>>> + (*hd) += >>>> fps_rate > 30 ? 1 : 2; >>>> + } else { >>>> + (*sd) += >>>> fps_rate > 30 ? 1 : 2; >>>> + } >>>> } >>>> } >>>> >>>> @@ -805,6 +856,7 @@ void >>>> radeon_uvd_note_usage(struct >>>> radeon_device >>>> *rdev) >>>> set_clocks &= >>>> >>>> schedule_delayed_work(&rdev->uvd.idle_work, >>>> >>>> msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); >>>> >>>> + >>>> if >>>> ((rdev->pm.pm_method == >>>> PM_METHOD_DPM) && >>>> rdev->pm.dpm_enabled) { >>>> unsigned hd = >>>> 0, sd = 0; >>>> >>>> radeon_uvd_count_handles(rdev, >>>> &sd, &hd); >>>> -- >>>> 1.9.1 >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Marco Antonio Benatto >>>> Linux user ID:#506236 >>> >> >> -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/3d1aee40/attachment-0001.sig>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

d_count_handles(struct >> radeon_device *rdev, >> if >> (!atomic_read(&rdev->uvd.handles[i])) >> continue; >> >> - if >> (rdev->uvd.img_size[i] >= 720*576) >> - ++(*hd); >> - else >> - ++(*sd); >> + fps_rate = >> radeon_uvd_estimate_fps(rdev, i); >> + >> + if >> (rdev->uvd.img_size[i] >= 720*576) { >> + (*hd) += >> fps_rate > 30 ? 1 : 2; >> + } else { >> + (*sd) += >> fps_rate > 30 ? 1 : 2; >> + } >> } >> } >> >> @@ -805,6 +856,7 @@ void >> radeon_uvd_note_usage(struct >> radeon_device >> *rdev) >> set_clocks &= >> >> schedule_delayed_work(&rdev->uvd.idle_work, >> >> msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); >> >> + >> if >> ((rdev->pm.pm_method == >> PM_METHOD_DPM) && >> rdev->pm.dpm_enabled) { >> unsigned hd = >> 0, sd = 0; >> >> radeon_uvd_count_handles(rdev, >> &sd, &hd); >> -- >> 1.9.1 >> >> >> >> >> >> -- >> Marco Antonio Benatto >> Linux user ID:#506236 > -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/e12cfa06/attachment.sig>

[PATCH] drm/radeon: Always flush VM again on < CIK

Hey guys, I think I've figured out what the cause of the remaining issues is while working on the implicit sync stuff. The issue happens when the flush is done because of a CS to the DMA ring and a CS to the GFX ring directly after that which depends on the DMA submission to be finished. In t

[Intel-gfx] [PATCH] drm: fix plane rotation when restoring fbdev configuration

On 15 August 2014 11:22, Daniel Vetter wrote: > On Fri, Aug 15, 2014 at 10:48:05AM +0100, Thomas Wood wrote: >> On 15 August 2014 10:42, Thomas Wood wrote: >> > On 14 August 2014 17:02, Daniel Vetter wrote: >> >> On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote: >> >>> Make sure plane

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

(*sd) += > fps_rate > 30 ? 1 : 2; > + } > } > } > > @@ -805,6 +856,7 @@ void > radeon_uvd_note_usage(struct > radeon_device > *rdev) > set_clocks &= > > schedule_delayed_work(&rdev->uvd.idle_work, > > msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); > > + > if > ((rdev->pm.pm_method == > PM_METHOD_DPM) && > rdev->pm.dpm_enabled) { > unsigned hd = > 0, sd = 0; > radeon_uvd_count_handles(rdev, > &sd, &hd); > -- > 1.9.1 > > > > > > -- > Marco Antonio Benatto > Linux user ID:#506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/75526780/attachment-0001.html>

[Bug 82586] UBO matrix in std140 struct does not work

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/20140815/014c7f9f/attachment.html>

[Bug 82586] UBO matrix in std140 struct does not work

d mesa yourself. -- 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/20140815/f122bb9a/attachment-0001.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

;>>> + unsigned i; >>>>>>>>> + >>>>>>>>> + fps->timestamp = >>>>>>>>> jiffies_64; >>>>>>&g

[Bug 71891] 3.13 fails to boot with the radeon module

https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #44 from Dino --- Solved. Last line before this happened was fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver It works after passing radeon.dpm=0 to boot options. -- You are receiving this mail because:

[Bug 82667] New: "Distance" game closed alpha: Changing shadow settings segfaults

nd with LIBGL_DRI3_DISABLE=1 -- 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/20140815/1d1fc228/attachment.html>

drm/radeon: giving userspace control over hardware engine sync

Am 14.08.2014 um 20:35 schrieb Jerome Glisse: > On Thu, Aug 14, 2014 at 06:12:01PM +0200, Christian K?nig wrote: >> Hello everyone, >> >> this set of patch adds the ability for userspace to better control when >> synchronization between the different hardware engines on radeon happens. >> Previousl

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

+ >>>>>> + if (valid > 0) >>>>>> + return count / >>>>>> valid; >>>>>> + else >>>>>> + return >>>>>> RADEON_UVD_DEFAULT_FPS; >>>>>> +} >>>>>> + >>>>>> void >>>>>> radeon_uvd_free_handles(struct >>>>>> radeon_device *rdev, struct >>>>>> drm_file *filp) >>>>>> { >>>>>> int i, r; >>>>>> @@ -419,8 +464,10 @@ static int >>>>>> radeon_uvd_cs_msg(struct >>>>>> radeon_cs_parser >>>>>> *p, struct radeon_bo *bo, >>>>>> >>>>>> /* create or decode, >>>>>> validate the handle */ >>>>>> for (i = 0; i < >>>>>> RADEON_MAX_UVD_HANDLES; ++i) { >>>>>> - if >>>>>> (atomic_read(&p->rdev->uvd. >>>>>> handles[i]) >>>>>> == handle) >>>>>> + if >>>>>> (atomic_read(&p->rdev->uvd. >>>>>> handles[i]) >>>>>> == handle) >>>>>> { >>>>>> + >>>>>> radeon_uvd_fps_note_event(p->rdev, >>>>>> i); >>>>>> >>>>>> return 0; >>>>>> + } >>>>>> } >>>>>> >>>>>> /* handle not found >>>>>> try to alloc a new one */ >>>>>> @@ -428,6 +475,7 @@ static int >>>>>> radeon_uvd_cs_msg(struct >>>>>> radeon_cs_parser >>>>>> *p, struct radeon_bo *bo, >>>>>> if >>>>>> (!atomic_cmpxchg(&p->rdev-> >>>>>> uvd.handles[i], >>>>>> 0, >>>>>> handle)) { >>>>>> >>>>>> p->rdev->uvd.filp[i] = p->filp; >>>>>> >>>>>> p->rdev->uvd.img_size[i] = >>>>>> img_size; >>>>>> + >>>>>> radeon_uvd_fps_clear_events(p- >>>>>> >rdev, >>>>>> i); >>>>>> >>>>>> return 0; >>>>>> } >>>>>> } >>>>>> @@ -763,7 +811,7 @@ int >>>>>> radeon_uvd_get_destroy_msg( >>>>>> struct >>>>>> radeon_device >>>>>> *rdev, int ring, >>>>>> static void >>>>>> radeon_uvd_count_handles(struct >>>>>> radeon_device *rdev, >>>>>> >>>>>> unsigned *sd, unsigned >>>>>> *hd) >>>>>> { >>>>>> - unsigned i; >>>>>> + unsigned i, fps_rate = 0; >>>>>> >>>>>> *sd = 0; >>>>>> *hd = 0; >>>>>> @@ -772,10 +820,13 @@ static void >>>>>> radeon_uvd_count_handles(struct >>>>>> radeon_device *rdev, >>>>>> if >>>>>> (!atomic_read(&rdev->uvd. >>>>>> handles[i])) >>>>>> >>>>>> continue; >>>>>> >>>>>> - if >>>>>> (rdev->uvd.img_size[i] >= >>>>>> 720*576) >>>>>> - ++(*hd); >>>>>> - else >>>>>> - ++(*sd); >>>>>> + fps_rate = >>>>>> radeon_uvd_estimate_fps(rdev, i); >>>>>> + >>>>>> + if >>>>>> (rdev->uvd.img_size[i] >= >>>>>> 720*576) { >>>>>> + (*hd) += >>>>>> fps_rate > 30 ? 1 : 2; >>>>>> + } else { >>>>>> + (*sd) += >>>>>> fps_rate > 30 ? 1 : 2; >>>>>> + } >>>>>> } >>>>>> } >>>>>> >>>>>> @@ -805,6 +856,7 @@ void >>>>>> radeon_uvd_note_usage(struct >>>>>> radeon_device >>>>>> *rdev) >>>>>> set_clocks &= >>>>>> schedule_delayed_work(&rdev-> >>>>>> uvd.idle_work, >>>>>> >>>>>> msecs_to_jiffies(UVD_IDLE_ >>>>>> TIMEOUT_MS)); >>>>>> >>>>>> + >>>>>> if >>>>>> ((rdev->pm.pm_method == >>>>>> PM_METHOD_DPM) && >>>>>> rdev->pm.dpm_enabled) { >>>>>> unsigned hd = >>>>>> 0, sd = 0; >>>>>> >>>>>> radeon_uvd_count_handles(rdev, >>>>>> &sd, &hd); >>>>>> -- >>>>>> 1.9.1 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Marco Antonio Benatto >>>>>> Linux user ID:#506236 >>>>>> >>>>> >>>> >> > -- Marco Antonio Benatto Linux user ID: #506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/7048c4db/attachment-0001.html>

[PATCH] drm/radeon: Revert try to enable VM flushing once more

From: Christian K?nig This reverts commit f77c4f0223a1f0e259007c7431f64df5c29a0bf7. Just had the afflatus why that doesn't work like it should and we need to revert it, cause it can happen on every hardware generation. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_vm.c | 6

[Patch] DRM support for addressing >32 bits on 32 bit cores (Radeon DRM driver+TTM)

available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/6f80ce40/attachment-0002.bin> -- next part -- A non-text attachment was scrubbed... Name: ttm.patch Type: text/x-patch Size: 424 bytes Desc: not available URL: <http://lists.freede

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

/* create or decode, > >>>> validate the handle */ > >>>> for (i = 0; i < > >>>> RADEON_MAX_UVD_HANDLES; ++i) { > >>>> - if > >>>> > (atomic_read(&p->rdev->uvd.handles[i]) > >>>> == handle) > >>>> + if > >>>> > (atomic_read(&p->rdev->uvd.handles[i]) > >>>> == handle) > >>>> { > >>>> + > >>>> > radeon_uvd_fps_note_event(p->rdev, i); > >>>> > return 0; > >>>> + } > >>>> } > >>>> > >>>> /* handle not found > >>>> try to alloc a new one */ > >>>> @@ -428,6 +475,7 @@ static int > >>>> radeon_uvd_cs_msg(struct > >>>> radeon_cs_parser > >>>> *p, struct radeon_bo *bo, > >>>> if > >>>> > (!atomic_cmpxchg(&p->rdev->uvd.handles[i], > >>>> 0, > >>>> handle)) { > >>>> > >>>> p->rdev->uvd.filp[i] = p->filp; > >>>> > >>>> p->rdev->uvd.img_size[i] = > img_size; > >>>> + > >>>> > radeon_uvd_fps_clear_events(p->rdev, > >>>> i); > >>>> > return 0; > >>>> } > >>>> } > >>>> @@ -763,7 +811,7 @@ int > >>>> radeon_uvd_get_destroy_msg(struct > >>>> radeon_device > >>>> *rdev, int ring, > >>>> static void > >>>> radeon_uvd_count_handles(struct > >>>> radeon_device *rdev, > >>>> > >>>>unsigned *sd, unsigned *hd) > >>>> { > >>>> - unsigned i; > >>>> + unsigned i, fps_rate = 0; > >>>> > >>>> *sd = 0; > >>>> *hd = 0; > >>>> @@ -772,10 +820,13 @@ static void > >>>> radeon_uvd_count_handles(struct > >>>> radeon_device *rdev, > >>>> if > >>>> > (!atomic_read(&rdev->uvd.handles[i])) > >>>> > continue; > >>>> > >>>> - if > >>>> (rdev->uvd.img_size[i] >= 720*576) > >>>> - ++(*hd); > >>>> - else > >>>> - ++(*sd); > >>>> + fps_rate = > >>>> radeon_uvd_estimate_fps(rdev, i); > >>>> + > >>>> + if > >>>> (rdev->uvd.img_size[i] >= > 720*576) { > >>>> + (*hd) += > >>>> fps_rate > 30 ? 1 : 2; > >>>> + } else { > >>>> + (*sd) += > >>>> fps_rate > 30 ? 1 : 2; > >>>> + } > >>>> } > >>>> } > >>>> > >>>> @@ -805,6 +856,7 @@ void > >>>> radeon_uvd_note_usage(struct > >>>> radeon_device > >>>> *rdev) > >>>> set_clocks &= > >>>> > schedule_delayed_work(&rdev->uvd.idle_work, > >>>> > >>>> > msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); > >>>> > >>>> + > >>>> if > >>>> ((rdev->pm.pm_method == > >>>> PM_METHOD_DPM) && > >>>> rdev->pm.dpm_enabled) { > >>>> unsigned hd = > >>>> 0, sd = 0; > >>>> > >>>> radeon_uvd_count_handles(rdev, > >>>> &sd, &hd); > >>>> -- > >>>> 1.9.1 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Marco Antonio Benatto > >>>> Linux user ID:#506236 > >>> > >> > >> > > > -- Marco Antonio Benatto Linux user ID: #506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/b637b443/attachment-0001.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Fri, Aug 15, 2014 at 1:03 PM, Marco Benatto wrote: > Grigori, Alex and Christian > > are you ok if I merge ioctl flag idea with sysfs idea? > > We let the system decide the state using the hint provided by CS ioctl flag > but if performance is not good as expected > or DPM table is not sane we

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Fri, Aug 15, 2014 at 12:46 PM, Grigori Goronzy wrote: > For reference, I forgot to send to you all. > > Forwarded Message > Subject: Re: [PATCH] drm/radeon: Adding UVD handle basis fps estimation v2 > Date: Fri, 15 Aug 2014 18:40:02 +0200 > From: Grigori Goronzy > To: Alex De

[Bug 71891] 3.13 fails to boot with the radeon module

https://bugzilla.kernel.org/show_bug.cgi?id=71891 Dino changed: What|Removed |Added CC||dino.omanovic.15 at gmail.com --- Comment #43 from

[Intel-gfx] [PATCH] drm: fix plane rotation when restoring fbdev configuration

On Fri, Aug 15, 2014 at 10:48:05AM +0100, Thomas Wood wrote: > On 15 August 2014 10:42, Thomas Wood wrote: > > On 14 August 2014 17:02, Daniel Vetter wrote: > >> On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote: > >>> Make sure plane rotation is reset correctly when restoring the fbdev

[PATCH] drm/radeon: properly document reloc priority mask

From: Christian K?nig Instead of hard coding the value properly document that this is an userspace interface. No intended functional change. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_cs.c | 3 ++- include/uapi/drm/radeon_drm.h | 1 + 2 files changed, 3 insertions(+

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

amp - fps->timestamp, >>>>>>>>>> 1ULL)); >>>>>>>>>> + >>>>>>>>>> + fps->timestamp = timestamp; >>>>>>>>>> + fps->events[index] = min(rate, 120u); >>>>>>>>>> +} >>>>>>>>>> + >>>>>>>>>> +static unsigned radeon_uvd_estimate_fps(struct radeon_device >>>>>>>>>> *rdev, >>>>>>>>>> int >>>>>>>>>> idx) >>>>>>>>>> +{ >>>>>>>>>> + struct radeon_uvd_fps *fps = &rdev->uvd.fps_info[idx]; >>>>>>>>>> + unsigned i, valid = 0, count = 0; >>>>>>>>>> + >>>>>>>>>> + for (i = 0; i < RADEON_UVD_FPS_EVENTS_MAX; i++) { >>>>>>>>>> + /* We should ignore zero values */ >>>>>>>>>> + if (fps->events[i] != 0) { >>>>>>>>>> + count += fps->events[i]; >>>>>>>>>> + valid++; >>>>>>>>>> + } >>>>>>>>>> + } >>>>>>>>>> + >>>>>>>>>> + if (valid > 0) >>>>>>>>>> + return count / valid; >>>>>>>>>> + else >>>>>>>>>> + return RADEON_UVD_DEFAULT_FPS; >>>>>>>>>> +} >>>>>>>>>> + >>>>>>>>>> void radeon_uvd_free_handles(struct radeon_device *rdev, >>>>>>>>>> struct >>>>>>>>>> drm_file *filp) >>>>>>>>>> { >>>>>>>>>> int i, r; >>>>>>>>>> @@ -419,8 +464,10 @@ static int radeon_uvd_cs_msg(struct >>>>>>>>>> radeon_cs_parser >>>>>>>>>> *p, struct radeon_bo *bo, >>>>>>>>>> >>>>>>>>>> /* create or decode, validate the handle */ >>>>>>>>>> for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) { >>>>>>>>>> - if (atomic_read(&p->rdev->uvd.handles[i]) == >>>>>>>>>> handle) >>>>>>>>>> + if (atomic_read(&p->rdev->uvd.handles[i]) == >>>>>>>>>> handle) >>>>>>>>>> { >>>>>>>>>> + radeon_uvd_fps_note_event(p->rdev, i); >>>>>>>>>> return 0; >>>>>>>>>> + } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> /* handle not found try to alloc a new one */ >>>>>>>>>> @@ -428,6 +475,7 @@ static int radeon_uvd_cs_msg(struct >>>>>>>>>> radeon_cs_parser >>>>>>>>>> *p, struct radeon_bo *bo, >>>>>>>>>> if (!atomic_cmpxchg(&p->rdev->uvd.handles[i], >>>>>>>>>> 0, >>>>>>>>>> handle)) { >>>>>>>>>> p->rdev->uvd.filp[i] = p->filp; >>>>>>>>>> p->rdev->uvd.img_size[i] = img_size; >>>>>>>>>> + radeon_uvd_fps_clear_events(p->rdev, i); >>>>>>>>>> return 0; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> @@ -763,7 +811,7 @@ int radeon_uvd_get_destroy_msg(struct >>>>>>>>>> radeon_device >>>>>>>>>> *rdev, int ring, >>>>>>>>>> static void radeon_uvd_count_handles(struct radeon_device >>>>>>>>>> *rdev, >>>>>>>>>> unsigned *sd, unsigned >>>>>>>>>> *hd) >>>>>>>>>> { >>>>>>>>>> - unsigned i; >>>>>>>>>> + unsigned i, fps_rate = 0; >>>>>>>>>> >>>>>>>>>> *sd = 0; >>>>>>>>>> *hd = 0; >>>>>>>>>> @@ -772,10 +820,13 @@ static void radeon_uvd_count_handles(struct >>>>>>>>>> radeon_device *rdev, >>>>>>>>>> if (!atomic_read(&rdev->uvd.handles[i])) >>>>>>>>>> continue; >>>>>>>>>> >>>>>>>>>> - if (rdev->uvd.img_size[i] >= 720*576) >>>>>>>>>> - ++(*hd); >>>>>>>>>> - else >>>>>>>>>> - ++(*sd); >>>>>>>>>> + fps_rate = radeon_uvd_estimate_fps(rdev, i); >>>>>>>>>> + >>>>>>>>>> + if (rdev->uvd.img_size[i] >= 720*576) { >>>>>>>>>> + (*hd) += fps_rate > 30 ? 1 : 2; >>>>>>>>>> + } else { >>>>>>>>>> + (*sd) += fps_rate > 30 ? 1 : 2; >>>>>>>>>> + } >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> @@ -805,6 +856,7 @@ void radeon_uvd_note_usage(struct >>>>>>>>>> radeon_device >>>>>>>>>> *rdev) >>>>>>>>>> set_clocks &= >>>>>>>>>> schedule_delayed_work(&rdev->uvd.idle_work, >>>>>>>>>> >>>>>>>>>> msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); >>>>>>>>>> >>>>>>>>>> + >>>>>>>>>> if ((rdev->pm.pm_method == PM_METHOD_DPM) && >>>>>>>>>> rdev->pm.dpm_enabled) { >>>>>>>>>> unsigned hd = 0, sd = 0; >>>>>>>>>> radeon_uvd_count_handles(rdev, &sd, &hd); >>>>>>>>>> -- >>>>>>>>>> 1.9.1 >>>>>>>>>> >>>>>>>>>> >> > > > -- > Marco Antonio Benatto > Linux user ID: #506236 > > > -- Marco Antonio Benatto Linux user ID: #506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/d83086c0/attachment-0001.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Fri, Aug 15, 2014 at 10:11 AM, Christian K?nig wrote: > Hi Marco, > > the problem with an CS ioctl flag is that we sometimes don't know how much > SCLK/MCLK boost is needed, for example when we do post processing in the > player using OpenGL and UVD decoding with VDPAU. In this case VDPAU don't

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Fri, Aug 15, 2014 at 11:20 AM, Grigori Goronzy wrote: > On 15.08.2014 16:11, Christian K?nig wrote: >> Hi Marco, >> >> the problem with an CS ioctl flag is that we sometimes don't know how >> much SCLK/MCLK boost is needed, for example when we do post processing >> in the player using OpenGL an

Fence, timeline and android sync points

On Fri, Aug 15, 2014 at 10:07:39AM +0200, Daniel Vetter wrote: > On Thu, Aug 14, 2014 at 07:03:44PM -0400, Jerome Glisse wrote: > > On Thu, Aug 14, 2014 at 11:23:01PM +0200, Daniel Vetter wrote: > > > On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse > > > wrote: > > > > Cost 1 uint32 per buffer and

Fence, timeline and android sync points

On Fri, Aug 15, 2014 at 08:54:38AM +0200, Thomas Hellstrom wrote: > On 08/14/2014 09:15 PM, Jerome Glisse wrote: > > On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote: > >> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse > >> wrote: > >>> Sucks because you can not do weird synchronizat

[Intel-gfx] [PATCH] drm: fix plane rotation when restoring fbdev configuration

On 15 August 2014 10:42, Thomas Wood wrote: > On 14 August 2014 17:02, Daniel Vetter wrote: >> On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote: >>> Make sure plane rotation is reset correctly when restoring the fbdev >>> configuration by using drm_mode_plane_set_obj_prop. This calls t

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

Hi guys, to make a long story short every time I watch a movie my laptop start to heat up because we always select the standard UVD power profile without actually measuring if that is necessary. Marco came up with a patch that seems to reliable measure the fps send down to the kernel and so to

[Intel-gfx] [PATCH] drm: fix plane rotation when restoring fbdev configuration

On 14 August 2014 17:02, Daniel Vetter wrote: > On Thu, Aug 14, 2014 at 04:33:18PM +0100, Thomas Wood wrote: >> Make sure plane rotation is reset correctly when restoring the fbdev >> configuration by using drm_mode_plane_set_obj_prop. This calls the >> driver's set_property callback and ensures t

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

ignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/cfff2eb6/attachment.html>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

t;>>>>> + struct radeon_uvd_fps *fps = &rdev->uvd.fps_info[idx]; >>>>>>>>> + unsigned i, valid = 0, count = 0; >>>>>>>>> + >>>>>>>>> + for (i = 0; i < RADEON_UVD_FPS_EVENTS_MAX; i++) { >>>>>>>>> + /* We should ignore zero values */ >>>>>>>>> + if (fps->events[i] != 0) { >>>>>>>>> + count += fps->events[i]; >>>>>>>>> + valid++; >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + if (valid > 0) >>>>>>>>> + return count / valid; >>>>>>>>> + else >>>>>>>>> + return RADEON_UVD_DEFAULT_FPS; >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> void radeon_uvd_free_handles(struct radeon_device *rdev, >>>>>>>>> struct >>>>>>>>> drm_file *filp) >>>>>>>>> { >>>>>>>>> int i, r; >>>>>>>>> @@ -419,8 +464,10 @@ static int radeon_uvd_cs_msg(struct >>>>>>>>> radeon_cs_parser >>>>>>>>> *p, struct radeon_bo *bo, >>>>>>>>> >>>>>>>>> /* create or decode, validate the handle */ >>>>>>>>> for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) { >>>>>>>>> - if (atomic_read(&p->rdev->uvd.handles[i]) == >>>>>>>>> handle) >>>>>>>>> + if (atomic_read(&p->rdev->uvd.handles[i]) == >>>>>>>>> handle) >>>>>>>>> { >>>>>>>>> + radeon_uvd_fps_note_event(p->rdev, i); >>>>>>>>> return 0; >>>>>>>>> + } >>>>>>>>> } >>>>>>>>> >>>>>>>>> /* handle not found try to alloc a new one */ >>>>>>>>> @@ -428,6 +475,7 @@ static int radeon_uvd_cs_msg(struct >>>>>>>>> radeon_cs_parser >>>>>>>>> *p, struct radeon_bo *bo, >>>>>>>>> if (!atomic_cmpxchg(&p->rdev->uvd.handles[i], >>>>>>>>> 0, >>>>>>>>> handle)) { >>>>>>>>> p->rdev->uvd.filp[i] = p->filp; >>>>>>>>> p->rdev->uvd.img_size[i] = img_size; >>>>>>>>> + radeon_uvd_fps_clear_events(p->rdev, i); >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> @@ -763,7 +811,7 @@ int radeon_uvd_get_destroy_msg(struct >>>>>>>>> radeon_device >>>>>>>>> *rdev, int ring, >>>>>>>>> static void radeon_uvd_count_handles(struct radeon_device >>>>>>>>> *rdev, >>>>>>>>> unsigned *sd, unsigned >>>>>>>>> *hd) >>>>>>>>> { >>>>>>>>> - unsigned i; >>>>>>>>> + unsigned i, fps_rate = 0; >>>>>>>>> >>>>>>>>> *sd = 0; >>>>>>>>> *hd = 0; >>>>>>>>> @@ -772,10 +820,13 @@ static void radeon_uvd_count_handles(struct >>>>>>>>> radeon_device *rdev, >>>>>>>>> if (!atomic_read(&rdev->uvd.handles[i])) >>>>>>>>> continue; >>>>>>>>> >>>>>>>>> - if (rdev->uvd.img_size[i] >= 720*576) >>>>>>>>> - ++(*hd); >>>>>>>>> - else >>>>>>>>> - ++(*sd); >>>>>>>>> + fps_rate = radeon_uvd_estimate_fps(rdev, i); >>>>>>>>> + >>>>>>>>> + if (rdev->uvd.img_size[i] >= 720*576) { >>>>>>>>> + (*hd) += fps_rate > 30 ? 1 : 2; >>>>>>>>> + } else { >>>>>>>>> + (*sd) += fps_rate > 30 ? 1 : 2; >>>>>>>>> + } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> @@ -805,6 +856,7 @@ void radeon_uvd_note_usage(struct radeon_device >>>>>>>>> *rdev) >>>>>>>>> set_clocks &= schedule_delayed_work(&rdev-> >>>>>>>>> uvd.idle_work, >>>>>>>>> >>>>>>>>> msecs_to_jiffies(UVD_IDLE_TIMEOUT_MS)); >>>>>>>>> >>>>>>>>> + >>>>>>>>> if ((rdev->pm.pm_method == PM_METHOD_DPM) && >>>>>>>>> rdev->pm.dpm_enabled) { >>>>>>>>> unsigned hd = 0, sd = 0; >>>>>>>>> radeon_uvd_count_handles(rdev, &sd, &hd); >>>>>>>>> -- >>>>>>>>> 1.9.1 >>>>>>>>> >>>>>>>>> > -- Marco Antonio Benatto Linux user ID: #506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/7c7d0191/attachment-0001.html>

Fence, timeline and android sync points

On Thu, Aug 14, 2014 at 07:03:44PM -0400, Jerome Glisse wrote: > On Thu, Aug 14, 2014 at 11:23:01PM +0200, Daniel Vetter wrote: > > On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse > > wrote: > > > Cost 1 uint32 per buffer and simple if without locking to check status of > > > a buffer. > > > > Ye

[PATCH 3/4] drm/radeon: add DONT_SYNC flag to CS relocs

Am 14.08.2014 um 23:06 schrieb Jerome Glisse: > On Thu, Aug 14, 2014 at 04:34:29PM -0400, Alex Deucher wrote: >> On Thu, Aug 14, 2014 at 2:43 PM, Jerome Glisse wrote: >>> On Thu, Aug 14, 2014 at 06:12:04PM +0200, Christian K?nig wrote: From: Christian K?nig This allows userspace to

[Bug 82517] [RADEONSI,VDPAU] SIGSEGV in map_msg_fb_buf called from ruvd_destroy, when closing a Tab with accelerated video player

K?nig --- Thanks for testing, sounds like we can close this now. -- 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/20140

[Bug 82517] [RADEONSI,VDPAU] SIGSEGV in map_msg_fb_buf called from ruvd_destroy, when closing a Tab with accelerated video player

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/ad19f105/attachment.html>

Fence, timeline and android sync points

On 08/14/2014 09:15 PM, Jerome Glisse wrote: > On Thu, Aug 14, 2014 at 08:47:16PM +0200, Daniel Vetter wrote: >> On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse wrote: >>> Sucks because you can not do weird synchronization like one i depicted in >>> another >>> mail in this thread and for as long

[Bug 74335] [UVD] vdpau has terrible performance on radeonsi (HD 7950)

: 3.1791% = 100.% -- 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/20140815/305ff64d/attachment.html>

[Bug 82455] Failed to allocate virtual address for buffer

signee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/0b85af36/attachment.html>

[Bug 82586] UBO matrix in std140 struct does not work

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

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #6 from Alex Deucher --- dpm is enabled by default in 3.17 so you don't need to append radeon.dpm=1 anymore to enable it. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #5 from Fede --- So the issue is fixed in 3.17? Using that kernel I should not need to use radeon.dpm=1 anymore? -- You are receiving this mail because: You are watching the assignee of the bug.

[git pull] drm fixes (mostly nouveau)

Hi Linus, one doc buidling fixes for a file that moved, along with a bunch of nouveau fixes, one a build problem on ARM. Dave. The following changes since commit 899552d6e84babd24611fd36ac7051068cb1eb2d: Merge branch 'misc' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild (20

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #4 from Alex Deucher --- (In reply to Fede from comment #3) > Hi Alex, > > In deed, adding radeon.dpm=1 works. > Can this be permanently fixed for everyone affected? The issues with dpm on btc asics were fixed in 3.16 and it's enabl

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #3 from Fede --- Hi Alex, In deed, adding radeon.dpm=1 works. I tested it after submitting the bug report since I went thru what the actual patch changed. Currently running kernel 3.16.0-5 and it works as long as radeon.dpm=1 is passe

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 fr

[Bug 82431] Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 --- Comment #1 from Fede --- Created attachment 146691 --> https://bugzilla.kernel.org/attachment.cgi?id=146691&action=edit Image of issue At times only a thin dotted line can be seen on the top, other times the content is displayed flickering,

[Bug 82431] New: Garbled screen on boot

https://bugzilla.kernel.org/show_bug.cgi?id=82431 Bug ID: 82431 Summary: Garbled screen on boot Product: Drivers Version: 2.5 Kernel Version: All after 3.13.6-20 Hardware: All OS: Linux Tree: Mainline

[Bug 82455] Failed to allocate virtual address for buffer

e for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/7dbd4e60/attachment.html>

[pull] radeon drm-fixes-3.17

Hi Dave, radeon fixes for 3.17, kind of all over the place (dpm, GPUVM, etc.) The following changes since commit 251964845fbf539781dd2c6406cb2ba1bf9eddd0: drm/doc: Refer to proper source file (2014-08-15 09:50:41 +1000) are available in the git repository at: git://people.freedesktop.org/~