date:20140815

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 i915 vblank patches postponed since the
fixups need this branch plus drm-intel-next merged together).

Cheers, Daniel


The following changes since commit 168c02ec06f891990617cee2abbba70858c071e7:

  drm: Fix race when checking for fb in the generic kms obj lookup (2014-08-05 
11:06:52 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/core-stuff-2014-08-15

for you to fetch changes up to 14f476fa24e81d0beea1aa14d763102958518d60:

  drm: Use the type of the array element when reallocating (2014-08-14 21:24:30 
+0200)


Chris Wilson (1):
  drm: Perform cmdline mode parsing during connector initialisation

Damien Lespiau (2):
  drm: Don't return 0 for a value used as a denominator
  drm: Use the type of the array element when reallocating

Daniel Vetter (10):
  drm: Don't grab an fb reference for the idr
  video/fbdev: Always built-in video= cmdline parsing
  drm: Add drm_plane/connector_index
  drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]
  drm: Handle legacy per-crtc locking with full acquire ctx
  drm: Move ->old_fb from crtc to plane
  drm: trylock modest locking for fbdev panics
  drm: Add a plane->reset hook
  drm/irq: Implement a generic vblank_wait function
  drm: Docbook fixes

Rob Clark (1):
  drm: idiot-proof vblank

Ville Syrj?l? (1):
  drm: Warn when leaking flip events on close

 drivers/gpu/drm/Kconfig|   1 +
 drivers/gpu/drm/drm_crtc.c | 306 ++---
 drivers/gpu/drm/drm_dp_mst_topology.c  |   3 +-
 drivers/gpu/drm/drm_edid.c |   2 +-
 drivers/gpu/drm/drm_fb_helper.c|  76 +---
 drivers/gpu/drm/drm_fops.c |   2 +
 drivers/gpu/drm/drm_irq.c  |  68 
 drivers/gpu/drm/drm_modes.c|   1 +
 drivers/gpu/drm/drm_modeset_lock.c | 213 ++-
 drivers/gpu/drm/drm_probe_helper.c |  17 ++
 drivers/gpu/drm/mgag200/mgag200_mode.c |  21 +--
 drivers/video/fbdev/Kconfig|   4 +
 drivers/video/fbdev/core/Makefile  |   1 +
 drivers/video/fbdev/core/fb_cmdline.c  | 110 
 drivers/video/fbdev/core/fbmem.c   |  92 --
 drivers/video/fbdev/core/modedb.c  |   3 -
 include/drm/drmP.h |   2 +
 include/drm/drm_crtc.h |  22 ++-
 include/drm/drm_fb_helper.h|   1 -
 include/drm/drm_modeset_lock.h |  16 ++
 20 files changed, 630 insertions(+), 331 deletions(-)
 create mode 100644 drivers/video/fbdev/core/fb_cmdline.c

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

[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)
- cleanup of the hsw/bdw ddi pll code, prep work for skl (Damien)
- dsi video burst mode support (Shobhit)
- piles of other chv fixes all over (Ville et. al.)
- cleanup of the ddi translation tables setup code (Damien)
- 180 deg rotation support (Ville & Sonika Jindal)

Cheers, Daniel


The following changes since commit a91576d7916f6cce76d30303e60e1ac47cf4a76d:

  drm/ttm: Pass GFP flags in order to avoid deadlock. (2014-08-05 10:54:19 
+1000)

are available in the git repository at:

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

for you to fetch changes up to 2c0827cffca8ac0c654b888c58a1989a5172f007:

  drm/i915: Update DRIVER_DATE to 20140808 (2014-08-08 20:44:59 +0200)


- Setting dp M2/N2 values plus state checker support (Vandana Kannan)
- chv power well support (Ville)
- DP training pattern 3 support for chv (Ville)
- cleanup of the hsw/bdw ddi pll code, prep work for skl (Damien)
- dsi video burst mode support (Shobhit)
- piles of other chv fixes all over (Ville et. al.)
- cleanup of the ddi translation tables setup code (Damien)
- 180 deg rotation support (Ville & Sonika Jindal)


Damien Lespiau (15):
  drm/i915: Specify when the PLL hw state fields are valid
  drm/i915: Add a space to the shared DPLL debug message
  drm/i915: Extract the HSW DDI selection code into its own function
  drm/i915: Extract the HSW/BDW shared dpll init code
  drm/i915: Restrict hsw_dp_set_ddi_pll_sel() to HSW/BDW
  drm/i915: Fix stale comment for intel_ddi_pll_select()
  drm/i915: Split the BDW/HSW specific shared pll selection
  drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific
  drm/i915: Split the CDCLK retrieval per-platform
  drm/i915: Gather the HDMI level shifter logic into one place
  drm/i915/bdw: Provide the BDW specific HDMI buffer translation table
  drm/i915/bdw: Remove the HDMI/DVI entry from the DP/eDP/FDI tables
  drm/i915: Remove now useless comments about the translation values
  drm/i915: Demote the DRRS messages to debug messages
  drm/i915: Introduce a for_each_intel_encoder() macro

Daniel Vetter (8):
  drm/i915: Update DRIVER_DATE to 20140725
  drm/i915: Don't require dev->struct_mutex in psr_match_conditions
  drm/i915: Tune done rc6 enabling output
  drm/i915: Tune down MCH_SSKPD values warning
  drm/i915: Make ddi_clock_gate() HSW/BDW specific
  drm/i915: Align intel_dsi*.c files a bit
  drm/i915: No busy-loop wait_for in the ring init code
  drm/i915: Update DRIVER_DATE to 20140808

Deepak S (1):
  drm/i915: Bring GPU Freq to min while suspending.

Gajanan Bhat (4):
  drm/i915: Update DDL only for current CRTC
  drm/i915: Generalize drain latency computation
  drm/i915: Round-up clock and limit drain latency
  drm/i915: Add sprite watermark programming for VLV and CHV

Imre Deak (2):
  drm/i915: factor out intel_edp_panel_vdd_sanitize
  drm/i915: fix VDD state tracking after system resume

Jesse Barnes (1):
  drm/i915: clean up PPGTT checking logic

Jiri Kosina (1):
  drm/i915: read HEAD register back in init_ring_common() to enforce 
ordering

Kenneth Graunke (2):
  drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
  drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround.

Mika Kuoppala (1):
  drm/i915: Don't accumulate hangcheck score on forward progress

Paulo Zanoni (2):
  d rm/i915: freeze display before the interrupts and GT
  drm/i915: remove duplicate register defines

Pavel Machek (1):
  drm/i915: work around warning in i915_gem_gtt

Rafael Barbalho (2):
  drm/i915: Fix crash when failing to parse MIPI VBT
  drm/i915: Fix read back of plane stride register

Rodrigo Vivi (5):
  drm/i915: Fix error state collecting
  drm/i915: Collect gtier properly on HSW.
  drm/i915: Fix DEIER and GTIER collecting for BDW.
  Revert "drm/i915: Enable semaphores on BDW"
  drm/i915: Introduce FBC False Color for debug purposes.

Shobhit Kumar (3):
  drm/i915: wait for all DSI FIFOs to be empty
  drm/i915: Add correct hw/sw config check for DSI encoder
  drm/i915: Add support for Video Burst Mode for MIPI DSI

Sonika Jindal (2):
  drm: Add rotation_property to mode_config
  drm: Resetting rotation property

Vandana Kannan (2):
  drm/i915: Set M2_N2 registers during mode set
  drm/i915: State readout and cross-checking for dp_m2_n2

Ville Syrj?l? (27):
  drm/i915: Fix threshold for choosing 32 vs. 64 precisions for

[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 possible I would like to have something like 
RADEON_MIN_UVD_POWER_LEVEL=(uvd_sd|uvd_hd|uvd_hd2|uvd|uvd_mvc) which 
forces a minimum level, but still let the kernel decide if we don't 
wouldn't want a higher level.

Christian.

Am 15.08.2014 um 19:10 schrieb Alex Deucher:
> 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 still will have a fallback way o override this
>> decision.
> For backwards compatibility. The CS ioctl flag should be an opt in
> flag, e.g., UVD_KERNEL_MANAGE_POWER_STATE.  That way there would be no
> change for old versions of mesa, but for newer versions of mesa, the
> UVD user mode driver could set the flag when there was no post
> processing for lower power usage and not set it when there was post
> processing for better performance.
>
> I'd rather not have a sysfs entry.  I'd prefer a mesa env var or drirc
> option to force the CS flag.
>
> Alex
>
>>
>> On Fri, Aug 15, 2014 at 1:54 PM, Christian K?nig > amd.com>
>> wrote:
>>> 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
>>> 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 has the slightest idea how high SCLK/MCLK must be and so
>>> can't give that info to the kernel either.
>>>
>> Maybe it's an acceptable workaround to simply disable dynamic UVD state
>> selection in case the UVD states only have a single power level. That
>> will avoid the performance issues on affected systems, while still
>> allowing dynamic UVD states on systems that have a saner DPM table
>> setup. I think it is mosly older systems that suffer from this.
>>
> That is exactly what we do now.
>
 Is it? In 3.17-wip, dynamic UVD state selection (according to active
 streams) is still completely disabled. It will always use the generic
 UVD state. In fact wasn't it reverted again because of the performance
 issues on some systems?
>>>
>>> This is the performance table of my laptop (at least the interesting
>>> parts), which I think is a typical example of the problem:
>>>
>>> [4.106772] == power state 1 ==
>>> [4.106774] ui class: performance
>>> [4.106776] internal class: none
>>> [4.106780] uvdvclk: 0 dclk: 0
>>> [4.106782] power level 0sclk: 2 vddc_index: 2
>>> [4.106784] power level 1sclk: 5 vddc_index: 2
>>> [4.106805] == power state 3 ==
>>> [4.106807] ui class: none
>>> [4.106808] internal class: uvd
>>> [4.106813] uvdvclk: 55000 dclk: 4
>>> [4.106816] power level 0sclk: 5 vddc_index: 2
>>> [4.106818] power level 1sclk: 5 vddc_index: 2
>>> [4.106820] status:
>>> [4.106822] == power state 4 ==
>>> [4.106823] ui class: battery
>>> [4.106825] internal class: uvd_hd
>>> [4.106831] uvdvclk: 4 dclk: 3
>>> [4.106833] power level 0sclk: 38000 vddc_index: 1
>>> [4.106835] power level 1sclk: 38000 vddc_index: 1
>>> [4.106839] == power state 5 ==
>>> [4.106841] ui class: battery
>>> [4.106843] internal class: uvd_sd
>>> [4.106848] uvdvclk: 4 dclk: 3
>>> [4.106850] power level 0sclk: 38000 vddc_index: 2
>>> [4.106853] power level 1sclk: 38000 vddc_index: 2
>>>
>>> As you can see we currently always select the performance level uvd, which
>>> results in selecting the maximum sclk/dclk and vclk. Unfortunately neither
>>> uvd, uvd_sd nor uvd_hd allows the hardware to switch the sclk once selected
>>> (it's a hardware limitation of older uvd blocks).
>>>
>>> So for all cases where this is interesting you actually always have only a
>>> single power level to choose from.
>>>
>>> Christian.
>>>
>>>
 Grigori

> Alex
>
>
>> Best regards
>> Grigori
>>
>>> Regards,
>>> Christian.
>>>
>>> Am 15.08.2014 um 15:21 schrieb Marco Benatto:
 Hey all,

 I also had a talk with Alex yesterday about post-processing issues

[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
 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 has the slightest idea how high SCLK/MCLK must be and so
 can't give that info to the kernel either.

>>> Maybe it's an acceptable workaround to simply disable dynamic UVD state
>>> selection in case the UVD states only have a single power level. That
>>> will avoid the performance issues on affected systems, while still
>>> allowing dynamic UVD states on systems that have a saner DPM table
>>> setup. I think it is mosly older systems that suffer from this.
>>>
>> That is exactly what we do now.
>>
> Is it? In 3.17-wip, dynamic UVD state selection (according to active
> streams) is still completely disabled. It will always use the generic
> UVD state. In fact wasn't it reverted again because of the performance
> issues on some systems?

This is the performance table of my laptop (at least the interesting 
parts), which I think is a typical example of the problem:

[4.106772] == power state 1 ==
[4.106774] ui class: performance
[4.106776] internal class: none
[4.106780] uvdvclk: 0 dclk: 0
[4.106782] power level 0sclk: 2 vddc_index: 2
[4.106784] power level 1sclk: 5 vddc_index: 2
[4.106805] == power state 3 ==
[4.106807] ui class: none
[4.106808] internal class: uvd
[4.106813] uvdvclk: 55000 dclk: 4
[4.106816] power level 0sclk: 5 vddc_index: 2
[4.106818] power level 1sclk: 5 vddc_index: 2
[4.106820] status:
[4.106822] == power state 4 ==
[4.106823] ui class: battery
[4.106825] internal class: uvd_hd
[4.106831] uvdvclk: 4 dclk: 3
[4.106833] power level 0sclk: 38000 vddc_index: 1
[4.106835] power level 1sclk: 38000 vddc_index: 1
[4.106839] == power state 5 ==
[4.106841] ui class: battery
[4.106843] internal class: uvd_sd
[4.106848] uvdvclk: 4 dclk: 3
[4.106850] power level 0sclk: 38000 vddc_index: 2
[4.106853] power level 1sclk: 38000 vddc_index: 2

As you can see we currently always select the performance level uvd, 
which results in selecting the maximum sclk/dclk and vclk. Unfortunately 
neither uvd, uvd_sd nor uvd_hd allows the hardware to switch the sclk 
once selected (it's a hardware limitation of older uvd blocks).

So for all cases where this is interesting you actually always have only 
a single power level to choose from.

Christian.

>
> Grigori
>
>> Alex
>>
>>
>>> Best regards
>>> Grigori
>>>
 Regards,
 Christian.

 Am 15.08.2014 um 15:21 schrieb Marco Benatto:
> Hey all,
>
> I also had a talk with Alex yesterday about post-processing issues
> when using dynamic UVD profiles and a chamge on CS ioctl
> including a flag to let user mode driver tell to the kernel which
> performance requirement it wants for post processing. A commom
> point for both discussion is to stablish the default values for these
> profiles, but probably this ioctl change would be more impacting/complex
> to implement than a sysfs entry.
>
> If a sysfs entry is anough for now I can handle the code to create it
> and, with your help, the code to setup the UVD profile requested
> through it.
>
> Is there any suggestion?
>
> Thanks all for your help,
>
>
> On Fri, Aug 15, 2014 at 5:48 AM, Christian K?nig
> mailto:christian.koenig at amd.com>> wrote:
>
>  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 together with knowing the frame
>  size of the video should allow us to select the right UVD power
>  profile.
>
>  The problem is that Alex (unnoticed by me) completely disabled
>  selecting the UVD profiles because of some issues with advanced
>  post processing discussed on IRC. The problem seems to be that the
>  lower UVD profiles have a to low SCLK/MCLK to handle the 3D load
>  that comes with scaling, deinterlacing etc...
>
>  I unfortunately don't have time for it, cause this only affects
>  the hardware generations R600-SI and not the newest one CIK. So
>  could

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

> >>>> max(timestamp - 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
> >>>> = >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(>rdev->uvd.handles[i])
> >>>> == handle)
> >>>> +   if
> >>>>   
>  (atomic_read(>rdev->uvd.handles[i])
> >>>> == handle)
> >>>> {
> >>>>

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

;>>> +   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(>rdev->uvd.handles[i])
>>>>>> == handle)
>>>>>> +   if
>>>>>> 
>>>>>> (atomic_read(>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(>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(>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(>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,
>>>>>> , );
>>>>>> --
>>>>>> 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: 820 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140815/d4084f84/attachment-0002.sig>
-- 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/d4084f84/attachment-0003.sig>

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

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

  Priority: medium
Bug ID: 82671
  Assignee: dri-devel at lists.freedesktop.org
   Summary: [r600g-evergreen][compute]Empty kernel execution
causes crash
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: damien.hilloulin at supelec.fr
  Hardware: All
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 104687
  --> https://bugs.freedesktop.org/attachment.cgi?id=104687=edit
Bug repro program source file

I gave a shot to opencl support on my evergreen card (cedar) with mesa git.
I noticed that with an empty kernel the program crash with:
evergreen_state.c:1827:evergreen_emit_vertex_buffers: Assertion `rbuffer'
failed.

I made a little debugging and I think that this is du to a bug in
evergreen_init_compute_state_functions from evergreen_compute.c .

The two concerned lines are

/* We always use at least one vertex buffer for parameters (id = 1)*/
ctx->cs_vertex_buffer_state.enabled_mask =
ctx->cs_vertex_buffer_state.dirty_mask = 0x2;

With an empty kernel there is in fact no vertex buffer used as far as I can
see.

By changing the two lines to
ctx->cs_vertex_buffer_state.enabled_mask =
ctx->cs_vertex_buffer_state.dirty_mask = 0x0;

It doesn't crash for me anymore.
However I am a total driver development noob so my interpretation (and
therefore fix) can be wrong.

You can find attacted the very small program to be able to cause the crash.

-- 
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/15c01a9c/attachment.html>

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

+}
>>>> +
>>>> +static unsigned
>>>> radeon_uvd_estimate_fps(struct
>>>> radeon_device *rdev,
>>>> int
>>>> idx)
>>>> +{
>>>> +   struct radeon_uvd_fps *fps
>>>> = >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(>rdev->uvd.handles[i])
>>>> == handle)
>>>> +   if
>>>> (atomic_read(>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(>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(>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(>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,
>>>> , );
>>>> --
>>>> 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

if
>> (atomic_read(>rdev->uvd.handles[i])
>> == handle)
>> +   if
>> (atomic_read(>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(>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(>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(>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,
>> , );
>> --
>> 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 this situation we insert semaphore command so that the GFX ring wait 
for the DMA ring to finish execution and normally don't flush on the GFX 
ring a second time (the flush should be done on the DMA ring and we 
waited for that to finish).

The problem here is that semaphores can't be executed on the PFP, so the 
PFP doesn't wait for the semaphore to be completed and happily starts 
fetching commands while the flush on the DMA ring isn't completed.

@Michel: can you give this branch a try and see if it now works for you: 
http://cgit.freedesktop.org/~deathsimple/linux/log/?h=vm-flushing

We should keep that behavior in mind should we switch to put IBs into 
normal BOs, cause when those a swapped out the synchronization won't 
wait for swapping them back in using the DMA as well.

Thanks,
Christian.

Am 12.08.2014 um 11:05 schrieb Christian K?nig:
> Am 11.08.2014 um 17:00 schrieb Alex Deucher:
>> On Mon, Aug 11, 2014 at 4:42 AM, Michel D?nzer  
>> wrote:
>>> On 08.08.2014 22:34, Alex Deucher wrote:
 On Fri, Aug 8, 2014 at 9:31 AM, Alex Deucher 
  wrote:
> On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer  
> wrote:
>> On 08.08.2014 17:44, Christian K?nig wrote:
>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher 
>> 
>> wrote:
>>> We should be using PFP as much as possible.  Does the attached
>>> patch help?
 Unfortunately not.
>>> Maybe add a readback of the VM base addr pointer to make sure 
>>> that the
>>> write has really reached the SBRM?
>> I'm not sure what exactly you're thinking of, but I'm happy to 
>> test any
>> patches you guys come up with. :)
>>
> Maybe some variant of this patch?
 Ignore that one.  typo.  Try this one instead.
>>> Thanks, but still no luck.
>> I'm out of ideas at the moment.  I'll apply your patch unless
>> Christian can think of anything else.
>
> Unfortunately not, so apply the patch for now.
>
> Christian.
>
>>
>> Alex
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

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

2014-08-15 Thread Thomas Wood

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 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 the rotation is actually
>> >>> changed.
>> >>>
>> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82236
>> >>> Signed-off-by: Thomas Wood 
>> >>
>> >> Commit message is missing the citation of the offending commit that
>> >> introduced this. With that addressed this is
>> >>
>> >> Reviewed-by: Daniel Vetter 
>> >>
>> >> And please cc all the people involved in the offending commit next time
>> >> around, too.
>> >
>> > The "reset" feature was introduced in commit 9783de2 (drm: Resetting
>> > rotation property), although it also looks like the issue was
>> > originally addressed in a previous version of the patch:
>> >
>> > http://lists.freedesktop.org/archives/dri-devel/2014-July/062981.html
>> >
>> > Although this version calls the driver's set_property directly rather
>> > than exporting drm_mode_plane_set_obj_prop.
>> >
>> > The final version of the patch contains a different change:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2014-August/065728.html
>>
>> So there were actually two different "v2" versions of the patch.
>
> Somehow I've thought this is for -fixes, but the patch is only in dinq. So
> merged, thanks.
> -Daniel

Is there any preference to calling set_property directly (as
originally fixed), as opposed to exporting and using
drm_mode_plane_set_obj_prop?

I have also pushed a patch for igt/kms_rotate_crc to add a testcase
for this issue:

http://lists.freedesktop.org/archives/intel-gfx/2014-August/050775.html

>
>>
>>
>>
>> >
>> >> -Daniel
>> >>> ---
>> >>>  drivers/gpu/drm/drm_crtc.c  | 25 -
>> >>>  drivers/gpu/drm/drm_fb_helper.c |  6 +++---
>> >>>  include/drm/drm_crtc.h  |  3 +++
>> >>>  3 files changed, 26 insertions(+), 8 deletions(-)
>> >>>
>> >>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >>> index f09b752..95f330a 100644
>> >>> --- a/drivers/gpu/drm/drm_crtc.c
>> >>> +++ b/drivers/gpu/drm/drm_crtc.c
>> >>> @@ -4175,12 +4175,25 @@ static int drm_mode_crtc_set_obj_prop(struct 
>> >>> drm_mode_object *obj,
>> >>>   return ret;
>> >>>  }
>> >>>
>> >>> -static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
>> >>> -   struct drm_property *property,
>> >>> -   uint64_t value)
>> >>> +/**
>> >>> + * drm_mode_plane_set_obj_prop - set the value of a property
>> >>> + * @plane: drm plane object to set property value for
>> >>> + * @property: property to set
>> >>> + * @val: value the property should be set to
>> >>> + *
>> >>> + * This functions sets a given property on a given plane object. This 
>> >>> function
>> >>> + * calls the driver's ->set_property callback and changes the software 
>> >>> state of
>> >>> + * the property if the callback succeeds.
>> >>> + *
>> >>> + * Returns:
>> >>> + * Zero on success, error code on failure.
>> >>> + */
>> >>> +int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
>> >>> + struct drm_property *property,
>> >>> + uint64_t value)
>> >>>  {
>> >>>   int ret = -EINVAL;
>> >>> - struct drm_plane *plane = obj_to_plane(obj);
>> >>> + struct drm_mode_object *obj = >base;
>> >>>
>> >>>   if (plane->funcs->set_property)
>> >>>   ret = plane->funcs->set_property(plane, property, value);
>> >>> @@ -4189,6 +4202,7 @@ static int drm_mode_plane_set_obj_prop(struct 
>> >>> drm_mode_object *obj,
>> >>>
>> >>>   return ret;
>> >>>  }
>> >>> +EXPORT_SYMBOL(drm_mode_plane_set_obj_prop);
>> >>>
>> >>>  /**
>> >>>   * drm_mode_getproperty_ioctl - get the current value of a object's 
>> >>> property
>> >>> @@ -4327,7 +4341,8 @@ int drm_mode_obj_set_property_ioctl(struct 
>> >>> drm_device *dev, void *data,
>> >>>   ret = drm_mode_crtc_set_obj_prop(arg_obj, property, 
>> >>> arg->value);
>> >>>   break;
>> >>>   case DRM_MODE_OBJECT_PLANE:
>> >>> - ret = drm_mode_plane_set_obj_prop(arg_obj, property, 
>> >>> arg->value);
>> >>> + ret = drm_mode_plane_set_obj_prop(obj_to_plane(arg_obj),
>> >>> +   property, arg->value);
>> >>>   break;
>> >>>   }
>> >>>
>> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> >>> b/drivers/gpu/drm/drm_fb_helper.c
>> >>> index 63d7b8e..0c0c39b 100644
>> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> >>> @@ -296,9 +296,9 @@ static bool restore_fbdev_mode(struct

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

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(>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(>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,
> , );
> --
> 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

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

--- Comment #7 from Ilia Mirkin  ---
Probably one of

http://cgit.freedesktop.org/mesa/mesa/commit/?id=d52202141ebe28cd9f8d305827552fafccb279fd
http://cgit.freedesktop.org/mesa/mesa/commit/?id=da9c3ed304be5d08ff989d61c6e2d1be8a845767

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

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

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

--- Comment #6 from Roland Scheidegger  ---
(In reply to comment #5)
> I have got new mesa from PPA and problem seems to be gone. How can I find
> exact commit fixing this, please?

Just use git bisect. That of course requires you to build 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

t;>>> =
>>>>>>>>>   (256 * 1024 * 1024) >>
>>>>>>>>> PAGE_SHIFT;
>>>>>>>>>}
>>>>>>>>>
>>>>>>>>>   +static void
>>>>>>>>>
>>>>>>>>> radeon_uvd_fps_clear_events(struct
>>>>>>>>>   radeon_device *rdev,
>>>>>>>>>   int
>>>>>>>>>   idx)
>>>>>>>>>   +{
>>>>>>>>>   +   struct radeon_uvd_fps
>>>>>>>>> *fps
>>>>>>>>>   = >uvd.fps_info[idx];
>>>>>>>>>   +   unsigned i;
>>>>>>>>>   +
>>>>>>>>>   +   fps->timestamp =
>>>>>>>>> jiffies_64;
>>>>>>>>>   +   fps->event_index = 0;
>>>>>>>>>   +   for (i = 0; i <
>>>>>>>>>   RADEON_UVD_FPS_EVENTS_MAX;
>>>>>>>>> i++)
>>>>>>>>>   +
>>>>>>>>>  fps->events[i] =
>>>>>>>>> 0;
>>>>>>>>>   +}
>>>>>>>>>   +
>>>>>>>>>   +static void
>>>>>>>>>   radeon_uvd_fps_note_event(
>>>>>>>>> struct
>>>>>>>>>   radeon_device *rdev,
>>>>>>>>>   int
>>>>>>>>>   idx)
>>>>>>>>>   +{
>>>>>>>>>   +   struct radeon_uvd_fps
>>>>>>>>> *fps
>>>>>>>>>   = >uvd.fps_info[idx];
>>>>>>>>>   +   uint64_t timestamp =
>>>>>>>>>   jiffies_64;
>>>>>>>>>   +   unsigned rate = 0;
>>>>>>>>>   +
>>>>>>>>>   +   uint8_t index =
>>>>>>>>>   fps->event_index++;
>>>>>>>>>   +   fps->event_index %=
>>>>>>>>>   RADEON_UVD_FPS_EVENTS_MAX;
>>>>>>>>>   +
>>>>>>>>>   +   rate = div64_u64(HZ,
>>>>>>>>>   max(timestamp -
>>>>>>>>> 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
>>>>>>>>>   = >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(>rdev->uvd.handles[i])
>>>>>>>>>   == handle)
>>>>>>>>>   +   if
>>>>>>>>>
>>>>>>>>> (atomic_read(>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(>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(>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(>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,
>>>>>>>>>   , );
>>>>>>>>>   --
>>>>>>>>>   1.9.1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Marco Antonio Benatto
>>>>>>>>> Linux user ID:#506236
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>
>>> --
>>> 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/6017d030/attachment-0001.html>

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

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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:
You are watching the assignee of the bug.

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

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

Priority: medium
Bug ID: 82667
Assignee: dri-devel at lists.freedesktop.org
Summary: "Distance" game closed alpha: Changing shadow settings
segfaults
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: haagch at frickel.club
Hardware: Other
Status: NEW
Version: git
Component: Drivers/Gallium/radeonsi
Product: Mesa

Created attachment 104682
--> https://bugs.freedesktop.org/attachment.cgi?id=104682=edit
full backtrace

For people who are part of the Closed Alpha and want to test: It doesn't happen
when changing the shadow levels between active levels.
But when changing shadows from off to any level or from any level to off, this
segfault happens every time.

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

It does not crash when I run it on intel. It also does not crash when I run it
on llvmpipe.

So it is possibly related to PRIME rather than radeonsi, unfortunately I can't
test without PRIME.

mesa git, linux 3.16, launched in steam with:
DRI_PRIME=1 GALLIUM_HUD="fps,VRAM-usage+GTT-usage" %command%
It happens with both dri3 offloading and 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.
>> Previously every access to a buffer object was serialized and concurrent
>> execution could only happen if command submissions didn't shared any
>> buffer handle.
> I must say i do not like the whole direction of abusing buffer object to be
> expose as fence to userspace. Allowing 0 sized bo was the first step in this
> bad direction.

I'm not very keen about it either, but I wanted to wait what's the final 
result of the fence discussion and how we want to expose them to 
userspace before switching to something else.

> I do understand it's lot easier to implement such things in isolation from
> other and that trying to design and get a common kernel subsystem accepted
> is way more painful and unpredictible.

Correct, comparing the history of GEM named handles and DMA-buf the idea 
should be relative clear what we should use. Well after all everything 
is just a file, isn't it?


>> Patch #1 in this series adds the ability to not only sync before the IB
>> execution, but also after it before the fence value is written. This is
>> a workaround because TTM currently can't handle multiple fences attached
>> to a single buffer object.
> We do not want multiple fences to be associated with a buffer object ever.

Well maybe we shouldn't use the wording associating the fence to the 
buffer, but rather protecting the buffer object by multiple fences. 
Otherwise it wouldn't be possible to allow concurrent access from 
different hardware engines to the same buffer object. What we should 
avoid clearly is exposing any of this to userspace.

> In fact i believe getting rid of fence associated to buffer object is what
> would make sense.

Yeah, agree. We should have a separated fence object that userspace can 
query. In the end it should probably be similar to a DMA-buf fd or a 
futex. Not sure how a sane interface would look like.

Christian.

>
> Others comment as a per patch reply.
>
> Cheers,
> J?r?me
>
>> Patch #2 allows concurrent execution of command submission if there is
>> only read only access to the same buffer.
>>
>> Patch #3 adds a DONT_SYNC flag to each buffer object send to the kernel
>> which allows userspace to explicitly note that concurrent access to a
>> buffer is ok. The usage of this flag is restricted in that way that each
>> operation the client doesn't knows about (eviction, access by other clients
>> etc...) is still implicitly synced to.
>>
>> Patch #4 adds a DONT_FENCE flag that tells the kernel to sync all operations
>> to a buffer handle, but don't fence that handle with the current command
>> submission. This is necessarily because we currently abuses zero sized buffer
>> objects as fence handles.
>>
>> Please review and comment,
>> Christian.
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

   +
>>>>>>  +   uint8_t index =
>>>>>>  fps->event_index++;
>>>>>>  +   fps->event_index %=
>>>>>>  RADEON_UVD_FPS_EVENTS_MAX;
>>>>>>  +
>>>>>>  +   rate = div64_u64(HZ,
>>>>>>  max(timestamp - 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
>>>>>>  = >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(>rdev->uvd.
>>>>>> handles[i])
>>>>>>  == handle)
>>>>>>  +   if
>>>>>>  (atomic_read(>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(>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(>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(>
>>>>>> 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,
>>>>>>  , );
>>>>>>  --
>>>>>>  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 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_vm.c 
b/drivers/gpu/drm/radeon/radeon_vm.c
index 058f200..8d15ce6 100644
--- a/drivers/gpu/drm/radeon/radeon_vm.c
+++ b/drivers/gpu/drm/radeon/radeon_vm.c
@@ -238,9 +238,9 @@ void radeon_vm_flush(struct radeon_device *rdev,
uint64_t pd_addr = radeon_bo_gpu_offset(vm->page_directory);

/* if we can't remember our last VM flush then flush now! */
-   /* XXX figure out why we have to flush all the time before CIK */
-   if (rdev->family < CHIP_BONAIRE ||
-   !vm->last_flush || pd_addr != vm->pd_gpu_addr) {
+   /* flushing only when needed doesn't work because of a hardware race
+  condition between the DMA and the GFX engines */
+   if (!vm->last_flush || true || pd_addr != vm->pd_gpu_addr) {
trace_radeon_vm_flush(pd_addr, ring, vm->id);
vm->pd_gpu_addr = pd_addr;
radeon_ring_vm_flush(rdev, ring, vm);
-- 
1.9.1

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

2014-08-15 Thread Andrej Krutak

Hello,

I was advised to send this stuff here ( 
https://bugs.freedesktop.org/show_bug.cgi?id=18154 ).

The patches are tested with a P3041 board and a TURKS radeon card. It appears 
that the radeon driver is already generic enough (so no major changes were 
needed there), fortunately.

I think esp. the TTM patch is clearly needed, but it may be incomplete...

-- 
Best regards | S pozdravom | Mit freundlichen Gr??en | Cordialement

Andrej Krutak
-- next part --
A non-text attachment was scrubbed...
Name: radeon.patch
Type: text/x-patch
Size: 1015 bytes
Desc: not 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.freedesktop.org/archives/dri-devel/attachments/20140815/6f80ce40/attachment-0003.bin>

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

>> *p, struct radeon_bo *bo,
> >>>>
> >>>> /* create or decode,
> >>>> validate the handle */
> >>>> for (i = 0; i <
> >>>> RADEON_MAX_UVD_HANDLES; ++i) {
> >>>> -   if
> >>>>
>  (atomic_read(>rdev->uvd.handles[i])
> >>>> == handle)
> >>>> +   if
> >>>>
>  (atomic_read(>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(>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(>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(>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,
> >>>> , );
> >>>> --
> >>>> 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 still will have a fallback way o override this
> decision.

For backwards compatibility. The CS ioctl flag should be an opt in
flag, e.g., UVD_KERNEL_MANAGE_POWER_STATE.  That way there would be no
change for old versions of mesa, but for newer versions of mesa, the
UVD user mode driver could set the flag when there was no post
processing for lower power usage and not set it when there was post
processing for better performance.

I'd rather not have a sysfs entry.  I'd prefer a mesa env var or drirc
option to force the CS flag.

Alex

>
>
> On Fri, Aug 15, 2014 at 1:54 PM, Christian K?nig 
> wrote:
>>
>> 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
>> 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 has the slightest idea how high SCLK/MCLK must be and so
>> can't give that info to the kernel either.
>>
> Maybe it's an acceptable workaround to simply disable dynamic UVD state
> selection in case the UVD states only have a single power level. That
> will avoid the performance issues on affected systems, while still
> allowing dynamic UVD states on systems that have a saner DPM table
> setup. I think it is mosly older systems that suffer from this.
>
 That is exactly what we do now.

>>> Is it? In 3.17-wip, dynamic UVD state selection (according to active
>>> streams) is still completely disabled. It will always use the generic
>>> UVD state. In fact wasn't it reverted again because of the performance
>>> issues on some systems?
>>
>>
>> This is the performance table of my laptop (at least the interesting
>> parts), which I think is a typical example of the problem:
>>
>> [4.106772] == power state 1 ==
>> [4.106774] ui class: performance
>> [4.106776] internal class: none
>> [4.106780] uvdvclk: 0 dclk: 0
>> [4.106782] power level 0sclk: 2 vddc_index: 2
>> [4.106784] power level 1sclk: 5 vddc_index: 2
>> [4.106805] == power state 3 ==
>> [4.106807] ui class: none
>> [4.106808] internal class: uvd
>> [4.106813] uvdvclk: 55000 dclk: 4
>> [4.106816] power level 0sclk: 5 vddc_index: 2
>> [4.106818] power level 1sclk: 5 vddc_index: 2
>> [4.106820] status:
>> [4.106822] == power state 4 ==
>> [4.106823] ui class: battery
>> [4.106825] internal class: uvd_hd
>> [4.106831] uvdvclk: 4 dclk: 3
>> [4.106833] power level 0sclk: 38000 vddc_index: 1
>> [4.106835] power level 1sclk: 38000 vddc_index: 1
>> [4.106839] == power state 5 ==
>> [4.106841] ui class: battery
>> [4.106843] internal class: uvd_sd
>> [4.106848] uvdvclk: 4 dclk: 3
>> [4.106850] power level 0sclk: 38000 vddc_index: 2
>> [4.106853] power level 1sclk: 38000 vddc_index: 2
>>
>> As you can see we currently always select the performance level uvd, which
>> results in selecting the maximum sclk/dclk and vclk. Unfortunately neither
>> uvd, uvd_sd nor uvd_hd allows the hardware to switch the sclk once selected
>> (it's a hardware limitation of older uvd blocks).
>>
>> So for all cases where this is interesting you actually always have only a
>> single power level to choose from.
>>
>> Christian.
>>
>>
>>>
>>> Grigori
>>>
 Alex


> Best regards
> Grigori
>
>> Regards,
>> Christian.
>>
>> Am 15.08.2014 um 15:21 schrieb Marco Benatto:
>>>
>>> Hey all,
>>>
>>> I also had a talk with Alex yesterday about post-processing issues
>>> when using dynamic UVD profiles and a chamge on CS ioctl
>>> including a flag to let user mode driver tell to the kernel which
>>> performance requirement it wants for post processing. A commom
>>> point for both discussion is to stablish the default values for these
>>> profiles, but probably this ioctl change would be more
>>> impacting/complex
>>> to implement than a sysfs entry.
>>>
>>> If a sysfs entry is anough for now I can handle the code to create it
>>> and, with your help, the code to setup the UVD profile requested
>>> through it.
>>>
>>> Is there any suggestion?
>>>
>>> Thanks all for

[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 Deucher 
>
> On 15.08.2014 17:45, Alex Deucher wrote:
>> Maybe I'm not understanding what you are proposing them.  UVD power
>> states fall into basically 3 categories:
>>
>> 1.  R6xx/r7xx/evergreen
>> - single UVD state
>>
>> 2.  older APUs/NI/SI
>> - multiple UVD states with different combinations of slck/mclk and uvd clocks
>>
>> 3.  CI+
>> - hw managed dynamic UVD clocks
>>
>> The second category is the problematic one and the only one where the
>> UVD state selection is a factor.  We really need better logic to
>> determine what sclks/mclk and uvd clks so we know which power state to
>> select.  The logic in the kernel is fine for determining the level of
>> uvd clks we need, but when post processing is enabled you also have to
>> take into account the levels of sclk/mclk needed for the 3D engine.
>>
>
> I mean the second category. On most systems, low (uvd_sd, uvd_hd) UVD
> power states appear to have multiple 3D power levels or a single 3D
> power level with clocks equal to the highest level in the "performance"
> power state. However on some systems, low UVD power states only have a
> single 3D power level that is noticeably slower than the maximum
> "performance" state power level. It's mostly these systems that are
> problematic, as far as I can see.
>
> My proposal is to detect this condition and disable usage of the low UVD
> power states (by default at least) on affected systems. Other systems
> can dynamically choose an UVD power state according to active streams.
> Of course this affects power consumption, but at least avoids the issue
> of crippled 3D performance in some scenarios. I don't see a good way to
> automatically select an appropriate UVD power state according to 3D
> load. Video post processing isn't the only possible scenario that needs
> a lot of 3D performance. There really isn't much that can be done.
>
> What do you think about this?

I don't think it will really help in practice.  Generally the cards
that have high gfx clks in the UVD states are desktop dGPUs so heat
and power are not really a concern.  Which basically leaves APUs and
mobile parts stuck in the highest UVD state and those are the ones
were you actually want the lower UVD states.  You don't really need
complex logic in the UVD user mode driver.  Just a flag to say post
processing is enabled, use the high performance UVD state, otherwise,
let the kernel pick based on streams.

Alex

>
> Grigori
>> Alex
>>
>>>
>>> Grigori
>>>
 Alex


> Best regards
> Grigori
>
>> Regards,
>> Christian.
>>
>> Am 15.08.2014 um 15:21 schrieb Marco Benatto:
>>> Hey all,
>>>
>>> I also had a talk with Alex yesterday about post-processing issues
>>> when using dynamic UVD profiles and a chamge on CS ioctl
>>> including a flag to let user mode driver tell to the kernel which
>>> performance requirement it wants for post processing. A commom
>>> point for both discussion is to stablish the default values for these
>>> profiles, but probably this ioctl change would be more impacting/complex
>>> to implement than a sysfs entry.
>>>
>>> If a sysfs entry is anough for now I can handle the code to create it
>>> and, with your help, the code to setup the UVD profile requested
>>> through it.
>>>
>>> Is there any suggestion?
>>>
>>> Thanks all for your help,
>>>
>>>
>>> On Fri, Aug 15, 2014 at 5:48 AM, Christian K?nig
>>> mailto:christian.koenig at amd.com>> 
>>> wrote:
>>>
>>> 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 together with knowing the frame
>>> size of the video should allow us to select the right UVD power
>>> profile.
>>>
>>> The problem is that Alex (unnoticed by me) completely disabled
>>> selecting the UVD profiles because of some issues with advanced
>>> post processing discussed on IRC. The problem seems to be that the
>>> lower UVD profiles have a to low SCLK/MCLK to handle the 3D load
>>> that comes with scaling, deinterlacing etc...
>>>
>>> I unfortunately don't have time for it, cause this only affects
>>> the hardware generations R600-SI and not the newest one CIK. So
>>> could you guys stick together and come up with a solution?
>>> Something like a sysfs entry that let's us

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

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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

Dino  changed:

   What|Removed |Added

 CC||dino.omanovic.15 at gmail.com

--- Comment #43 from Dino  ---
I have similar issue which seems to occur since 3.12 kernel.
I get [drm] initialized then I get this weird screen.
http://imgbox.com/LXh03H2o
It hangs up at that point, so I have to hold power button then power it on
again.
It does boot with radeon.modeset=0 
Graphics is HD7640G Trinity (AMD A8-4500M, microcode is ARUBA) and laptop is
ASUS K55N-DS81.

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

[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
> >>> configuration by using drm_mode_plane_set_obj_prop. This calls the
> >>> driver's set_property callback and ensures the rotation is actually
> >>> changed.
> >>>
> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82236
> >>> Signed-off-by: Thomas Wood 
> >>
> >> Commit message is missing the citation of the offending commit that
> >> introduced this. With that addressed this is
> >>
> >> Reviewed-by: Daniel Vetter 
> >>
> >> And please cc all the people involved in the offending commit next time
> >> around, too.
> >
> > The "reset" feature was introduced in commit 9783de2 (drm: Resetting
> > rotation property), although it also looks like the issue was
> > originally addressed in a previous version of the patch:
> >
> > http://lists.freedesktop.org/archives/dri-devel/2014-July/062981.html
> >
> > Although this version calls the driver's set_property directly rather
> > than exporting drm_mode_plane_set_obj_prop.
> >
> > The final version of the patch contains a different change:
> 
> http://lists.freedesktop.org/archives/dri-devel/2014-August/065728.html
> 
> So there were actually two different "v2" versions of the patch.

Somehow I've thought this is for -fixes, but the patch is only in dinq. So
merged, thanks.
-Daniel

> 
> 
> 
> >
> >> -Daniel
> >>> ---
> >>>  drivers/gpu/drm/drm_crtc.c  | 25 -
> >>>  drivers/gpu/drm/drm_fb_helper.c |  6 +++---
> >>>  include/drm/drm_crtc.h  |  3 +++
> >>>  3 files changed, 26 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >>> index f09b752..95f330a 100644
> >>> --- a/drivers/gpu/drm/drm_crtc.c
> >>> +++ b/drivers/gpu/drm/drm_crtc.c
> >>> @@ -4175,12 +4175,25 @@ static int drm_mode_crtc_set_obj_prop(struct 
> >>> drm_mode_object *obj,
> >>>   return ret;
> >>>  }
> >>>
> >>> -static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
> >>> -   struct drm_property *property,
> >>> -   uint64_t value)
> >>> +/**
> >>> + * drm_mode_plane_set_obj_prop - set the value of a property
> >>> + * @plane: drm plane object to set property value for
> >>> + * @property: property to set
> >>> + * @val: value the property should be set to
> >>> + *
> >>> + * This functions sets a given property on a given plane object. This 
> >>> function
> >>> + * calls the driver's ->set_property callback and changes the software 
> >>> state of
> >>> + * the property if the callback succeeds.
> >>> + *
> >>> + * Returns:
> >>> + * Zero on success, error code on failure.
> >>> + */
> >>> +int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
> >>> + struct drm_property *property,
> >>> + uint64_t value)
> >>>  {
> >>>   int ret = -EINVAL;
> >>> - struct drm_plane *plane = obj_to_plane(obj);
> >>> + struct drm_mode_object *obj = >base;
> >>>
> >>>   if (plane->funcs->set_property)
> >>>   ret = plane->funcs->set_property(plane, property, value);
> >>> @@ -4189,6 +4202,7 @@ static int drm_mode_plane_set_obj_prop(struct 
> >>> drm_mode_object *obj,
> >>>
> >>>   return ret;
> >>>  }
> >>> +EXPORT_SYMBOL(drm_mode_plane_set_obj_prop);
> >>>
> >>>  /**
> >>>   * drm_mode_getproperty_ioctl - get the current value of a object's 
> >>> property
> >>> @@ -4327,7 +4341,8 @@ int drm_mode_obj_set_property_ioctl(struct 
> >>> drm_device *dev, void *data,
> >>>   ret = drm_mode_crtc_set_obj_prop(arg_obj, property, 
> >>> arg->value);
> >>>   break;
> >>>   case DRM_MODE_OBJECT_PLANE:
> >>> - ret = drm_mode_plane_set_obj_prop(arg_obj, property, 
> >>> arg->value);
> >>> + ret = drm_mode_plane_set_obj_prop(obj_to_plane(arg_obj),
> >>> +   property, arg->value);
> >>>   break;
> >>>   }
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> >>> b/drivers/gpu/drm/drm_fb_helper.c
> >>> index 63d7b8e..0c0c39b 100644
> >>> --- a/drivers/gpu/drm/drm_fb_helper.c
> >>> +++ b/drivers/gpu/drm/drm_fb_helper.c
> >>> @@ -296,9 +296,9 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
> >>> *fb_helper)
> >>>   drm_plane_force_disable(plane);
> >>>
> >>>   if (dev->mode_config.rotation_property) {
> >>> - drm_object_property_set_value(>base,
> >>> - dev->mode_config.rotation_property,
> >>> - BIT(DRM_ROTATE_0));
> >>> + drm_mode_plane_set_obj_prop(plane,
> >>> +

[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(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index ee712c1..cb12df7 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -132,7 +132,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser 
*p)
 * the buffers used for read only, which doubles the range
 * to 0 to 31. 32 is reserved for the kernel driver.
 */
-   priority = (r->flags & 0xf) * 2 + !!r->write_domain;
+   priority = (r->flags & RADEON_RELOC_PRIO_MASK) * 2
+  + !!r->write_domain;

/* the first reloc of an UVD job is the msg and that must be in
   VRAM, also but everything into VRAM on AGP cards to avoid
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 509b2d7..fea6099 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -944,6 +944,7 @@ struct drm_radeon_cs_chunk {
 };

 /* drm_radeon_cs_reloc.flags */
+#define RADEON_RELOC_PRIO_MASK (0xf << 0)

 struct drm_radeon_cs_reloc {
uint32_thandle;
-- 
1.9.1

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

>>>>>>>> +   uint8_t event_index;
>>>>>>>>>> +   uint8_t events[RADEON_UVD_FPS_EVENTS_MAX];
>>>>>>>>>> +};
>>>>>>>>>> +
>>>>>>>>>>  struct radeon_uvd {
>>>>>>>>>> struct radeon_bo*vcpu_bo;
>>>>>>>>>> void*cpu_addr;
>>>>>>>>>> @@ -1626,6 +1635,7 @@ struct radeon_uvd {
>>>>>>>>>> struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
>>>>>>>>>> unsigned
>>>>>>>>>> img_size[RADEON_MAX_UVD_HANDLES];
>>>>>>>>>> struct delayed_work idle_work;
>>>>>>>>>> +   struct radeon_uvd_fps   fps_info[RADEON_MAX_UVD_HANDLES];
>>>>>>>>>>  };
>>>>>>>>>>
>>>>>>>>>>  int radeon_uvd_init(struct radeon_device *rdev);
>>>>>>>>>> diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
>>>>>>>>>> b/drivers/gpu/drm/radeon/radeon_uvd.c
>>>>>>>>>> index 6bf55ec..ef5667a 100644
>>>>>>>>>> --- a/drivers/gpu/drm/radeon/radeon_uvd.c
>>>>>>>>>> +++ b/drivers/gpu/drm/radeon/radeon_uvd.c
>>>>>>>>>> @@ -237,6 +237,51 @@ void radeon_uvd_force_into_uvd_segment(struct
>>>>>>>>>> radeon_bo *rbo)
>>>>>>>>>> rbo->placement.lpfn = (256 * 1024 * 1024) >>
>>>>>>>>>> PAGE_SHIFT;
>>>>>>>>>>  }
>>>>>>>>>>
>>>>>>>>>> +static void radeon_uvd_fps_clear_events(struct radeon_device
>>>>>>>>>> *rdev,
>>>>>>>>>> int
>>>>>>>>>> idx)
>>>>>>>>>> +{
>>>>>>>>>> +   struct radeon_uvd_fps *fps = >uvd.fps_info[idx];
>>>>>>>>>> +   unsigned i;
>>>>>>>>>> +
>>>>>>>>>> +   fps->timestamp = jiffies_64;
>>>>>>>>>> +   fps->event_index = 0;
>>>>>>>>>> +   for (i = 0; i < RADEON_UVD_FPS_EVENTS_MAX; i++)
>>>>>>>>>> +   fps->events[i] = 0;
>>>>>>>>>> +}
>>>>>>>>>> +
>>>>>>>>>> +static void radeon_uvd_fps_note_event(struct radeon_device *rdev,
>>>>>>>>>> int
>>>>>>>>>> idx)
>>>>>>>>>> +{
>>>>>>>>>> +   struct radeon_uvd_fps *fps = >uvd.fps_info[idx];
>>>>>>>>>> +   uint64_t timestamp = jiffies_64;
>>>>>>>>>> +   unsigned rate = 0;
>>>>>>>>>> +
>>>>>>>>>> +   uint8_t index = fps->event_index++;
>>>>>>>>>> +   fps->event_index %= RADEON_UVD_FPS_EVENTS_MAX;
>>>>>>>>>> +
>>>>>>>>>> +   rate = div64_u64(HZ, max(timestamp - 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 = >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(>rdev->uvd.handles[i]) ==
>>>>>>>>>> handle)
>>>>>>>>>> +   if (atomic_read(>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(>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(>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(>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, , );
>>>>>>>>>> --
>>>>>>>>>> 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
> has the slightest idea how high SCLK/MCLK must be and so can't give that
> info to the kernel either.

It could be as simple as just setting a flag when any kind of post
processing is enabled so that the kernel selects the highest UVD
performance state, otherwise, let the kernel decide based on streams.

Alex


>
> Regards,
> Christian.
>
> Am 15.08.2014 um 15:21 schrieb Marco Benatto:
>
> Hey all,
>
> I also had a talk with Alex yesterday about post-processing issues when
> using dynamic UVD profiles and a chamge on CS ioctl
> including a flag to let user mode driver tell to the kernel which
> performance requirement it wants for post processing. A commom
> point for both discussion is to stablish the default values for these
> profiles, but probably this ioctl change would be more impacting/complex
> to implement than a sysfs entry.
>
> If a sysfs entry is anough for now I can handle the code to create it and,
> with your help, the code to setup the UVD profile requested through it.
>
> Is there any suggestion?
>
> Thanks all for your help,
>
>
> On Fri, Aug 15, 2014 at 5:48 AM, Christian K?nig 
> wrote:
>>
>> 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 together with knowing the frame size of the video
>> should allow us to select the right UVD power profile.
>>
>> The problem is that Alex (unnoticed by me) completely disabled selecting
>> the UVD profiles because of some issues with advanced post processing
>> discussed on IRC. The problem seems to be that the lower UVD profiles have a
>> to low SCLK/MCLK to handle the 3D load that comes with scaling,
>> deinterlacing etc...
>>
>> I unfortunately don't have time for it, cause this only affects the
>> hardware generations R600-SI and not the newest one CIK. So could you guys
>> stick together and come up with a solution? Something like a sysfs entry
>> that let's us select the minimum UVD power level allowed?
>>
>> I think Marco is happy to come up with a patch, we just need to know
>> what's really needed and what should be the default values. I'm happy to
>> review everything that comes out of it, just don't have time to do it
>> myself.
>>
>> Happy discussion and thanks in advance,
>> Christian.
>>
>> Am 12.08.2014 um 15:05 schrieb Alex Deucher:
>>
>>> On Tue, Aug 12, 2014 at 6:00 AM, Christian K?nig
>>>  wrote:

 Am 11.08.2014 um 16:52 schrieb Alex Deucher:

> On Mon, Aug 11, 2014 at 5:08 AM, Christian K?nig
>  wrote:
>>
>> Am 07.08.2014 um 21:43 schrieb Alex Deucher:
>>
>>> On Thu, Aug 7, 2014 at 11:32 AM, Christian K?nig
>>>  wrote:

 Am 07.08.2014 um 16:32 schrieb Alex Deucher:

> On Thu, Aug 7, 2014 at 7:33 AM, Christian K?nig
> 
> wrote:
>>
>> From: Marco A Benatto 
>>
>> Adding a Frames Per Second estimation logic on UVD handles
>> when it has being used. This estimation is per handle basis
>> and will help on DPM profile calculation.
>>
>> v2 (chk): fix timestamp type, move functions around and
>>   cleanup code a bit.
>
> Will this really help much?  I thought the problem was mainly due
> to
> sclk and mclk for post processing.


 It should at least handle the UVD side for upclocking when you get a
 lot
 of
 streams / fps. And at on my NI the patch seems to do exactly that.

 Switching sclk and mclk for post processing is a different task, and
 I
 actually have no idea what to do with them.
>>>
>>> At this point we always choose the plain UVD state anyway so this
>>> patch would only take effect if we re-enabled the dynamic UVD state
>>> selection.
>>
>>
>> Hui? I thought we already re-enabled the dynamic UVD state selection,
>> but
>> double checking this I found it disabled again.
>>
>> What was the problem with that? Looks like I somehow missed the
>> discussion
>> around it.
>
> We did, but after doing so a number of people complained about a
> regression on IRC because when apps like xmbc enabled post processing,
> performance went down.


 That's strange, from my experience the different UVD performance states
 only
 affect UVDs dclk/vclk, not sclk/mclk. I need to get the DPM dumps to
 confirms this.

[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 and UVD decoding with VDPAU. In this case
>> VDPAU don't has the slightest idea how high SCLK/MCLK must be and so
>> can't give that info to the kernel either.
>>
>
> Maybe it's an acceptable workaround to simply disable dynamic UVD state
> selection in case the UVD states only have a single power level. That
> will avoid the performance issues on affected systems, while still
> allowing dynamic UVD states on systems that have a saner DPM table
> setup. I think it is mosly older systems that suffer from this.
>

That is exactly what we do now.

Alex


> Best regards
> Grigori
>
>> Regards,
>> Christian.
>>
>> Am 15.08.2014 um 15:21 schrieb Marco Benatto:
>>> Hey all,
>>>
>>> I also had a talk with Alex yesterday about post-processing issues
>>> when using dynamic UVD profiles and a chamge on CS ioctl
>>> including a flag to let user mode driver tell to the kernel which
>>> performance requirement it wants for post processing. A commom
>>> point for both discussion is to stablish the default values for these
>>> profiles, but probably this ioctl change would be more impacting/complex
>>> to implement than a sysfs entry.
>>>
>>> If a sysfs entry is anough for now I can handle the code to create it
>>> and, with your help, the code to setup the UVD profile requested
>>> through it.
>>>
>>> Is there any suggestion?
>>>
>>> Thanks all for your help,
>>>
>>>
>>> On Fri, Aug 15, 2014 at 5:48 AM, Christian K?nig
>>> mailto:christian.koenig at amd.com>> wrote:
>>>
>>> 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 together with knowing the frame
>>> size of the video should allow us to select the right UVD power
>>> profile.
>>>
>>> The problem is that Alex (unnoticed by me) completely disabled
>>> selecting the UVD profiles because of some issues with advanced
>>> post processing discussed on IRC. The problem seems to be that the
>>> lower UVD profiles have a to low SCLK/MCLK to handle the 3D load
>>> that comes with scaling, deinterlacing etc...
>>>
>>> I unfortunately don't have time for it, cause this only affects
>>> the hardware generations R600-SI and not the newest one CIK. So
>>> could you guys stick together and come up with a solution?
>>> Something like a sysfs entry that let's us select the minimum UVD
>>> power level allowed?
>>>
>>> I think Marco is happy to come up with a patch, we just need to
>>> know what's really needed and what should be the default values.
>>> I'm happy to review everything that comes out of it, just don't
>>> have time to do it myself.
>>>
>>> Happy discussion and thanks in advance,
>>> Christian.
>>>
>>> Am 12.08.2014 um 15:05 schrieb Alex Deucher:
>>>
>>> On Tue, Aug 12, 2014 at 6:00 AM, Christian K?nig
>>> mailto:deathsimple at vodafone.de>> 
>>> wrote:
>>>
>>> Am 11.08.2014 um 16:52 schrieb Alex Deucher:
>>>
>>> On Mon, Aug 11, 2014 at 5:08 AM, Christian K?nig
>>> >> > wrote:
>>>
>>> Am 07.08.2014 um 21:43 schrieb Alex Deucher:
>>>
>>> On Thu, Aug 7, 2014 at 11:32 AM, Christian K?nig
>>> >> > wrote:
>>>
>>> Am 07.08.2014 um 16:32 schrieb Alex Deucher:
>>>
>>> On Thu, Aug 7, 2014 at 7:33 AM,
>>> Christian K?nig
>>> >> >
>>> wrote:
>>>
>>> From: Marco A Benatto
>>> >> >
>>>
>>> Adding a Frames Per Second
>>> estimation logic on UVD handles
>>> when it has being used. This
>>> estimation is per handle basis
>>> and will help on DPM profile
>>> calculation.
>>>
>>> v2 (chk): fix timestamp type, move
>>> functions around and
>>>

Fence, timeline and android sync points

2014-08-15 Thread Jerome Glisse

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 simple if without locking to check status 
> > > > of
> > > > a buffer.
> > > 
> > > Yeah well except it doesn't and that's why we switch to full blown
> > > fence objects internally instead of smacking seqno values all over the
> > > place. At least in i915 because I have seen what this "simple"
> > > solution looks like if you throw all the complexities into the bin and
> > > mix it well.
> > 
> > I am kind of curious on what can go wrong here ? Unless you have thousands
> > of different hw block inside your gpu all of them with different cmd queue
> > then i do not see any issue.
> 
> See my other reply, but because we'll schedule software contexts here and
> we need to do it with implicit fencing because we can't just break the
> existing world. The below is pretty much the design we currently have.

Software need the object to be binded to the gpu gart on intel ? That's bad.
But even with such thing, you can do it as a secondary lock only for user
space.

> -Daniel
> 
> > 
> > Note that this global seqno i am talking is only useful for bind/unbind of
> > buffer in ideal world of explicit sync, not for synchronization btw command
> > buffer. So pseudo code would be :
> > 
> > // if buffer_can_unbind(buf, dev) return true then buffer is no longer in
> > // use and can be unbind. if false you can wait on the device wait queue.
> > bool buffer_can_unbind(buf, dev)
> > {
> >   // Is the last gseqno associated with buffer is smaller than current
> >   // smallest signaled seqno ?
> >   if (buf->gseqno <= dev->gseqno_cmin)
> > return true;
> >   hw_update_gseqno_min(dev);
> >   if (buf->gseqno <= dev->gseqno_cmin)
> > return true;
> >   for_each_hw_block(hwblock, dev) {
> > // If that hwblock has not signaled a gseqno bigger than the
> > // buffer one's and also has work scheduled that might be using
> > // the buffer (ie the last scheduled gseqno is greater than
> > // buffer gseqno). If that's true than buffer might still be
> > // in use so assume the worst.
> > if (hwblock->gseqno < buf->gseqno &&
> > hwblock->gseqno_last_scheduled >= buf->gseqno)
> >   return false;
> > // This means either this block is already past the buf->gseqno
> > // or that this block have nothing in its pipeline that will ever
> > // use buf.
> > // As an extra optimization one might add a hwblock mask to buf
> > // and unmask wait for that hwblock so further wait will not wait
> > // on this block as we know for sure it's not involve.
> >   }
> >   // Well none of the hwblock is still using that buffer.
> >   return true;
> > }
> > 
> > hw_update_gseqno_min(dev)
> > {
> >unsigned nmin = -1;
> > 
> >for_each_hw_block(hwblock, dev) {
> >  nmin = min(nmin, hwblock->gseqno);
> >}
> >// atomic exchange and compage set new min only if it's bigger then
> >// current min
> >atomic_cmp_xchg(dev->gseqno_cmin, nmin)
> > }
> > 
> > 
> > So this is how it looks in my mind, each hwblock write to there dedicated
> > >gseqno and for each hwblock you store the last gseqno that was scheduled.
> > There is no need for any lock and this is outside any other sync mecanism.
> > 
> > For hw with preemption, i assume you have then have a hwcontext, well you
> > use same code except that now you have a gseqno per context which means
> > you need to store a seqno per context per buffer. With some trickery this
> > might be avoided especialy if hw can do atomic cmp_xchg.
> > 
> > Cheers,
> > J?r?me
> > 
> > 
> > > -Daniel
> > > -- 
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

Fence, timeline and android sync points

2014-08-15 Thread Jerome Glisse

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 synchronization like one i depicted in 
> >>> another
> >>> mail in this thread and for as long as cmdbuf_ioctl do not give you 
> >>> fence|syncpt
> >>> you can not such thing cleanly in non hackish way.
> >> Actually i915 can soon will do that that.
> > So you will return fence|syncpoint with each cmdbuf_ioctl ?
> >
> >>> Sucks because you have a fence object per buffer object and thus overhead 
> >>> grow
> >>> with the number of objects. Not even mentioning fence lifetime issue.
> >>>
> >>> Sucks because sub-buffer allocation is just one of many tricks that can 
> >>> not be
> >>> achieved properly and cleanly with implicit sync.
> >>>
> >>> ...
> >> Well I heard all those reasons and I'm well of aware of them. The
> >> problem is that with current hardware the kernel needs to know for
> >> each buffer how long it needs to be kept around since hw just can't do
> >> page faulting. Yeah you can pin them but for an uma design that
> >> doesn't go down well with folks.
> > I am not thinking with fancy hw in mind, on contrary i thought about all
> > this with the crappiest hw i could think of, in mind.
> >
> > Yes you can get rid of fence and not have to pin memory with current hw.
> > What matter for unpinning is to know that all hw block are done using the
> > memory. This is easily achievable with your beloved seqno. Have one seqno
> > per driver (one driver can have different block 3d, video decoding, crtc,
> > ...) each time a buffer is use as part of a command on one block inc the
> > common seqno and tag the buffer with that number. Have each hw block write
> > the lastest seqno that is done to a per block location. Now to determine
> > is buffer is done compare the buffer seqno with the max of all the signaled
> > seqno of all blocks.
> >
> > Cost 1 uint32 per buffer and simple if without locking to check status of
> > a buffer.
> 
> Hmm?
> The trivial and first use of fence objects in the linux DRM was
> triggered by the fact that a
> 32-bit seqno wraps pretty quickly and a 32-bit solution just can't be
> made robust.
> Now a 64-bit seqno will probably be robust for forseeable future, but
> when it comes to implement that on 32-bit hardware and compare it to a
> simple fence object approach,

Using same kind of arithemic as use for jiffies would do it provided that
there is a checking that we never let someobject pass above a certain age.

> 
> /Thomas
> 
>

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

2014-08-15 Thread Thomas Wood

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 the
>>> driver's set_property callback and ensures the rotation is actually
>>> changed.
>>>
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82236
>>> Signed-off-by: Thomas Wood 
>>
>> Commit message is missing the citation of the offending commit that
>> introduced this. With that addressed this is
>>
>> Reviewed-by: Daniel Vetter 
>>
>> And please cc all the people involved in the offending commit next time
>> around, too.
>
> The "reset" feature was introduced in commit 9783de2 (drm: Resetting
> rotation property), although it also looks like the issue was
> originally addressed in a previous version of the patch:
>
> http://lists.freedesktop.org/archives/dri-devel/2014-July/062981.html
>
> Although this version calls the driver's set_property directly rather
> than exporting drm_mode_plane_set_obj_prop.
>
> The final version of the patch contains a different change:

http://lists.freedesktop.org/archives/dri-devel/2014-August/065728.html

So there were actually two different "v2" versions of the patch.



>
>> -Daniel
>>> ---
>>>  drivers/gpu/drm/drm_crtc.c  | 25 -
>>>  drivers/gpu/drm/drm_fb_helper.c |  6 +++---
>>>  include/drm/drm_crtc.h  |  3 +++
>>>  3 files changed, 26 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index f09b752..95f330a 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -4175,12 +4175,25 @@ static int drm_mode_crtc_set_obj_prop(struct 
>>> drm_mode_object *obj,
>>>   return ret;
>>>  }
>>>
>>> -static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
>>> -   struct drm_property *property,
>>> -   uint64_t value)
>>> +/**
>>> + * drm_mode_plane_set_obj_prop - set the value of a property
>>> + * @plane: drm plane object to set property value for
>>> + * @property: property to set
>>> + * @val: value the property should be set to
>>> + *
>>> + * This functions sets a given property on a given plane object. This 
>>> function
>>> + * calls the driver's ->set_property callback and changes the software 
>>> state of
>>> + * the property if the callback succeeds.
>>> + *
>>> + * Returns:
>>> + * Zero on success, error code on failure.
>>> + */
>>> +int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
>>> + struct drm_property *property,
>>> + uint64_t value)
>>>  {
>>>   int ret = -EINVAL;
>>> - struct drm_plane *plane = obj_to_plane(obj);
>>> + struct drm_mode_object *obj = >base;
>>>
>>>   if (plane->funcs->set_property)
>>>   ret = plane->funcs->set_property(plane, property, value);
>>> @@ -4189,6 +4202,7 @@ static int drm_mode_plane_set_obj_prop(struct 
>>> drm_mode_object *obj,
>>>
>>>   return ret;
>>>  }
>>> +EXPORT_SYMBOL(drm_mode_plane_set_obj_prop);
>>>
>>>  /**
>>>   * drm_mode_getproperty_ioctl - get the current value of a object's 
>>> property
>>> @@ -4327,7 +4341,8 @@ int drm_mode_obj_set_property_ioctl(struct drm_device 
>>> *dev, void *data,
>>>   ret = drm_mode_crtc_set_obj_prop(arg_obj, property, 
>>> arg->value);
>>>   break;
>>>   case DRM_MODE_OBJECT_PLANE:
>>> - ret = drm_mode_plane_set_obj_prop(arg_obj, property, 
>>> arg->value);
>>> + ret = drm_mode_plane_set_obj_prop(obj_to_plane(arg_obj),
>>> +   property, arg->value);
>>>   break;
>>>   }
>>>
>>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>>> b/drivers/gpu/drm/drm_fb_helper.c
>>> index 63d7b8e..0c0c39b 100644
>>> --- a/drivers/gpu/drm/drm_fb_helper.c
>>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>>> @@ -296,9 +296,9 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
>>> *fb_helper)
>>>   drm_plane_force_disable(plane);
>>>
>>>   if (dev->mode_config.rotation_property) {
>>> - drm_object_property_set_value(>base,
>>> - dev->mode_config.rotation_property,
>>> - BIT(DRM_ROTATE_0));
>>> + drm_mode_plane_set_obj_prop(plane,
>>> + 
>>> dev->mode_config.rotation_property,
>>> + BIT(DRM_ROTATE_0));
>>>   }
>>>   }
>>>
>>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>>> index 0375d75..31344bf 100644
>>> --- a/include/drm/drm_crtc.h
>>> +++ b/include/drm/drm_crtc.h
>>> @@ -1127,6 +1127,9 @@ extern int

[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 together with knowing the frame size of the 
video should allow us to select the right UVD power profile.

The problem is that Alex (unnoticed by me) completely disabled selecting 
the UVD profiles because of some issues with advanced post processing 
discussed on IRC. The problem seems to be that the lower UVD profiles 
have a to low SCLK/MCLK to handle the 3D load that comes with scaling, 
deinterlacing etc...

I unfortunately don't have time for it, cause this only affects the 
hardware generations R600-SI and not the newest one CIK. So could you 
guys stick together and come up with a solution? Something like a sysfs 
entry that let's us select the minimum UVD power level allowed?

I think Marco is happy to come up with a patch, we just need to know 
what's really needed and what should be the default values. I'm happy to 
review everything that comes out of it, just don't have time to do it 
myself.

Happy discussion and thanks in advance,
Christian.

Am 12.08.2014 um 15:05 schrieb Alex Deucher:
> On Tue, Aug 12, 2014 at 6:00 AM, Christian K?nig
>  wrote:
>> Am 11.08.2014 um 16:52 schrieb Alex Deucher:
>>
>>> On Mon, Aug 11, 2014 at 5:08 AM, Christian K?nig
>>>  wrote:
 Am 07.08.2014 um 21:43 schrieb Alex Deucher:

> On Thu, Aug 7, 2014 at 11:32 AM, Christian K?nig
>  wrote:
>> Am 07.08.2014 um 16:32 schrieb Alex Deucher:
>>
>>> On Thu, Aug 7, 2014 at 7:33 AM, Christian K?nig
>>> 
>>> wrote:
 From: Marco A Benatto 

 Adding a Frames Per Second estimation logic on UVD handles
 when it has being used. This estimation is per handle basis
 and will help on DPM profile calculation.

 v2 (chk): fix timestamp type, move functions around and
   cleanup code a bit.
>>> Will this really help much?  I thought the problem was mainly due to
>>> sclk and mclk for post processing.
>>
>> It should at least handle the UVD side for upclocking when you get a
>> lot
>> of
>> streams / fps. And at on my NI the patch seems to do exactly that.
>>
>> Switching sclk and mclk for post processing is a different task, and I
>> actually have no idea what to do with them.
> At this point we always choose the plain UVD state anyway so this
> patch would only take effect if we re-enabled the dynamic UVD state
> selection.

 Hui? I thought we already re-enabled the dynamic UVD state selection, but
 double checking this I found it disabled again.

 What was the problem with that? Looks like I somehow missed the
 discussion
 around it.
>>> We did, but after doing so a number of people complained about a
>>> regression on IRC because when apps like xmbc enabled post processing,
>>> performance went down.
>>
>> That's strange, from my experience the different UVD performance states only
>> affect UVDs dclk/vclk, not sclk/mclk. I need to get the DPM dumps to
>> confirms this.
>>
> The sclks and mclks are usually different as well, especially on APUs.
> I can send you some examples.
>
>> You not off hand remember who complained on IRC? Finding something in the
>> IRC logs is like searching for a needle in a haystack.
> I don't remember off hand.  I think zgreg was involved in some of the
> discussions.
>
> Alex
>
>> Thanks,
>> Christian.
>>
>>
>>> Alex
>>>
>>>
 Christian.

> For the post processing, we probably need a hint we can
> pass to the driver in the CS ioctl to denote what state we need.
> Although if we did that, this could would largely be moot.  That said,
> newer asics support dynamic UVD clocks so we really only need
> something like that for older asics and I guess VCE.
>
> Alex
>
>> Christian.
>>
>>
>>> Alex
>>>
 Signed-off-by: Marco A Benatto 
 Signed-off-by: Christian K?nig 
 ---
  drivers/gpu/drm/radeon/radeon.h | 10 ++
  drivers/gpu/drm/radeon/radeon_uvd.c | 64
 +
  2 files changed, 68 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h
 b/drivers/gpu/drm/radeon/radeon.h
 index 9e1732e..e92f6cb 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -1617,6 +1617,15 @@ int radeon_pm_get_type_index(struct
 radeon_device
 *rdev,
  #define RADEON_UVD_STACK_SIZE  (1024*1024)
  #define RADEON_UVD_HEAP_SIZE   (1024*1024)

 +#define RADEON_UVD_FPS_EVENTS_MAX 8
 +#define RADEON_UVD_DEFAULT_FPS 60

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

2014-08-15 Thread Thomas Wood

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 the rotation is actually
>> changed.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82236
>> Signed-off-by: Thomas Wood 
>
> Commit message is missing the citation of the offending commit that
> introduced this. With that addressed this is
>
> Reviewed-by: Daniel Vetter 
>
> And please cc all the people involved in the offending commit next time
> around, too.

The "reset" feature was introduced in commit 9783de2 (drm: Resetting
rotation property), although it also looks like the issue was
originally addressed in a previous version of the patch:

http://lists.freedesktop.org/archives/dri-devel/2014-July/062981.html

Although this version calls the driver's set_property directly rather
than exporting drm_mode_plane_set_obj_prop.

The final version of the patch contains a different change:



> -Daniel
>> ---
>>  drivers/gpu/drm/drm_crtc.c  | 25 -
>>  drivers/gpu/drm/drm_fb_helper.c |  6 +++---
>>  include/drm/drm_crtc.h  |  3 +++
>>  3 files changed, 26 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index f09b752..95f330a 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -4175,12 +4175,25 @@ static int drm_mode_crtc_set_obj_prop(struct 
>> drm_mode_object *obj,
>>   return ret;
>>  }
>>
>> -static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
>> -   struct drm_property *property,
>> -   uint64_t value)
>> +/**
>> + * drm_mode_plane_set_obj_prop - set the value of a property
>> + * @plane: drm plane object to set property value for
>> + * @property: property to set
>> + * @val: value the property should be set to
>> + *
>> + * This functions sets a given property on a given plane object. This 
>> function
>> + * calls the driver's ->set_property callback and changes the software 
>> state of
>> + * the property if the callback succeeds.
>> + *
>> + * Returns:
>> + * Zero on success, error code on failure.
>> + */
>> +int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
>> + struct drm_property *property,
>> + uint64_t value)
>>  {
>>   int ret = -EINVAL;
>> - struct drm_plane *plane = obj_to_plane(obj);
>> + struct drm_mode_object *obj = >base;
>>
>>   if (plane->funcs->set_property)
>>   ret = plane->funcs->set_property(plane, property, value);
>> @@ -4189,6 +4202,7 @@ static int drm_mode_plane_set_obj_prop(struct 
>> drm_mode_object *obj,
>>
>>   return ret;
>>  }
>> +EXPORT_SYMBOL(drm_mode_plane_set_obj_prop);
>>
>>  /**
>>   * drm_mode_getproperty_ioctl - get the current value of a object's property
>> @@ -4327,7 +4341,8 @@ int drm_mode_obj_set_property_ioctl(struct drm_device 
>> *dev, void *data,
>>   ret = drm_mode_crtc_set_obj_prop(arg_obj, property, 
>> arg->value);
>>   break;
>>   case DRM_MODE_OBJECT_PLANE:
>> - ret = drm_mode_plane_set_obj_prop(arg_obj, property, 
>> arg->value);
>> + ret = drm_mode_plane_set_obj_prop(obj_to_plane(arg_obj),
>> +   property, arg->value);
>>   break;
>>   }
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 63d7b8e..0c0c39b 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -296,9 +296,9 @@ static bool restore_fbdev_mode(struct drm_fb_helper 
>> *fb_helper)
>>   drm_plane_force_disable(plane);
>>
>>   if (dev->mode_config.rotation_property) {
>> - drm_object_property_set_value(>base,
>> - dev->mode_config.rotation_property,
>> - BIT(DRM_ROTATE_0));
>> + drm_mode_plane_set_obj_prop(plane,
>> + 
>> dev->mode_config.rotation_property,
>> + BIT(DRM_ROTATE_0));
>>   }
>>   }
>>
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 0375d75..31344bf 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -1127,6 +1127,9 @@ extern int drm_mode_obj_get_properties_ioctl(struct 
>> drm_device *dev, void *data,
>>struct drm_file *file_priv);
>>  extern int drm_mode_obj_set_property_ioctl(struct drm_device *dev, void 
>> *data,
>>  struct drm_file *file_priv);
>> +extern int

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

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

--- Comment #86 from madcatx at atlas.cz ---
You're the man, Pali! I just tried the modified patch and it works for me too.
Glamor, OpenGL and vdpau seem to be working perfectly 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/20140815/cfff2eb6/attachment.html>

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

> radeon_bo *rbo)
>>>>>>>>> rbo->placement.lpfn = (256 * 1024 * 1024) >>
>>>>>>>>> PAGE_SHIFT;
>>>>>>>>>  }
>>>>>>>>>
>>>>>>>>> +static void radeon_uvd_fps_clear_events(struct radeon_device
>>>>>>>>> *rdev,
>>>>>>>>> int
>>>>>>>>> idx)
>>>>>>>>> +{
>>>>>>>>> +   struct radeon_uvd_fps *fps = >uvd.fps_info[idx];
>>>>>>>>> +   unsigned i;
>>>>>>>>> +
>>>>>>>>> +   fps->timestamp = jiffies_64;
>>>>>>>>> +   fps->event_index = 0;
>>>>>>>>> +   for (i = 0; i < RADEON_UVD_FPS_EVENTS_MAX; i++)
>>>>>>>>> +   fps->events[i] = 0;
>>>>>>>>> +}
>>>>>>>>> +
>>>>>>>>> +static void radeon_uvd_fps_note_event(struct radeon_device *rdev,
>>>>>>>>> int
>>>>>>>>> idx)
>>>>>>>>> +{
>>>>>>>>> +   struct radeon_uvd_fps *fps = >uvd.fps_info[idx];
>>>>>>>>> +   uint64_t timestamp = jiffies_64;
>>>>>>>>> +   unsigned rate = 0;
>>>>>>>>> +
>>>>>>>>> +   uint8_t index = fps->event_index++;
>>>>>>>>> +   fps->event_index %= RADEON_UVD_FPS_EVENTS_MAX;
>>>>>>>>> +
>>>>>>>>> +   rate = div64_u64(HZ, max(timestamp - 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 = >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(>rdev->uvd.handles[i]) ==
>>>>>>>>> handle)
>>>>>>>>> +   if (atomic_read(>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(>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(>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(>
>>>>>>>>> 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, , );
>>>>>>>>> --
>>>>>>>>> 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.
> > 
> > Yeah well except it doesn't and that's why we switch to full blown
> > fence objects internally instead of smacking seqno values all over the
> > place. At least in i915 because I have seen what this "simple"
> > solution looks like if you throw all the complexities into the bin and
> > mix it well.
> 
> I am kind of curious on what can go wrong here ? Unless you have thousands
> of different hw block inside your gpu all of them with different cmd queue
> then i do not see any issue.

See my other reply, but because we'll schedule software contexts here and
we need to do it with implicit fencing because we can't just break the
existing world. The below is pretty much the design we currently have.
-Daniel

> 
> Note that this global seqno i am talking is only useful for bind/unbind of
> buffer in ideal world of explicit sync, not for synchronization btw command
> buffer. So pseudo code would be :
> 
> // if buffer_can_unbind(buf, dev) return true then buffer is no longer in
> // use and can be unbind. if false you can wait on the device wait queue.
> bool buffer_can_unbind(buf, dev)
> {
>   // Is the last gseqno associated with buffer is smaller than current
>   // smallest signaled seqno ?
>   if (buf->gseqno <= dev->gseqno_cmin)
> return true;
>   hw_update_gseqno_min(dev);
>   if (buf->gseqno <= dev->gseqno_cmin)
> return true;
>   for_each_hw_block(hwblock, dev) {
> // If that hwblock has not signaled a gseqno bigger than the
> // buffer one's and also has work scheduled that might be using
> // the buffer (ie the last scheduled gseqno is greater than
> // buffer gseqno). If that's true than buffer might still be
> // in use so assume the worst.
> if (hwblock->gseqno < buf->gseqno &&
> hwblock->gseqno_last_scheduled >= buf->gseqno)
>   return false;
> // This means either this block is already past the buf->gseqno
> // or that this block have nothing in its pipeline that will ever
> // use buf.
> // As an extra optimization one might add a hwblock mask to buf
> // and unmask wait for that hwblock so further wait will not wait
> // on this block as we know for sure it's not involve.
>   }
>   // Well none of the hwblock is still using that buffer.
>   return true;
> }
> 
> hw_update_gseqno_min(dev)
> {
>unsigned nmin = -1;
> 
>for_each_hw_block(hwblock, dev) {
>  nmin = min(nmin, hwblock->gseqno);
>}
>// atomic exchange and compage set new min only if it's bigger then
>// current min
>atomic_cmp_xchg(dev->gseqno_cmin, nmin)
> }
> 
> 
> So this is how it looks in my mind, each hwblock write to there dedicated
> >gseqno and for each hwblock you store the last gseqno that was scheduled.
> There is no need for any lock and this is outside any other sync mecanism.
> 
> For hw with preemption, i assume you have then have a hwcontext, well you
> use same code except that now you have a gseqno per context which means
> you need to store a seqno per context per buffer. With some trickery this
> might be avoided especialy if hw can do atomic cmp_xchg.
> 
> Cheers,
> J?r?me
> 
> 
> > -Daniel
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[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 explicitly don't sync submission to
 different rings as long as all uses stay in the same client.

 Signed-off-by: Christian K?nig 
 ---
   drivers/gpu/drm/radeon/radeon.h |  3 +++
   drivers/gpu/drm/radeon/radeon_cs.c  | 23 ++-
   drivers/gpu/drm/radeon/radeon_gem.c |  1 +
   drivers/gpu/drm/radeon/radeon_ttm.c |  3 +++
   include/uapi/drm/radeon_drm.h   |  2 ++
   5 files changed, 31 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h 
 b/drivers/gpu/drm/radeon/radeon.h
 index c0f7773..740a0b2 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -478,6 +478,8 @@ struct radeon_bo {
u32 tiling_flags;
u32 pitch;
int surface_reg;
 + struct drm_file *last_user;
 + struct radeon_fence *last_sync;
struct radeon_fence *written;
/* list of all virtual address to which this bo
 * is associated to
 @@ -1018,6 +1020,7 @@ struct radeon_cs_reloc {
unsignedallowed_domains;
uint32_ttiling_flags;
uint32_thandle;
 + uint32_tflags;
boolwritten;
   };

 diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
 b/drivers/gpu/drm/radeon/radeon_cs.c
 index 3aa7e48..11e4789 100644
 --- a/drivers/gpu/drm/radeon/radeon_cs.c
 +++ b/drivers/gpu/drm/radeon/radeon_cs.c
 @@ -166,6 +166,7 @@ static int radeon_cs_parser_relocs(struct 
 radeon_cs_parser *p)

p->relocs[i].tv.bo = >relocs[i].robj->tbo;
p->relocs[i].handle = r->handle;
 + p->relocs[i].flags = r->flags;
p->relocs[i].written = !!r->write_domain;

radeon_cs_buckets_add(, >relocs[i].tv.head,
 @@ -236,6 +237,14 @@ static void radeon_cs_sync_rings(struct 
 radeon_cs_parser *p)
if (!bo)
continue;

 + /* always sync to the last operation
 +the clients doesn't know about */
 + radeon_semaphore_sync_to(p->ib.presync, bo->last_sync);
 +
 + if (bo->last_user == p->filp &&
 + reloc->flags & RADEON_RELOC_DONT_SYNC)
 + continue;
 +
fence = bo->tbo.sync_obj;

if (bo->written && radeon_fence_signaled(bo->written))
 @@ -421,7 +430,19 @@ static void radeon_cs_parser_fini(struct 
 radeon_cs_parser *parser, int error, bo
struct radeon_cs_reloc *reloc = >relocs[i];
struct radeon_bo *bo = reloc->robj;

 - if (!bo || !reloc->written)
 + if (!bo)
 + continue;
 +
 + /* if the client changes remember that and always 
 serialize
 +all operations from different clients */
 + if (bo->last_user != parser->filp && 
 bo->tbo.sync_obj) {
 + struct radeon_fence *fence = 
 bo->tbo.sync_obj;
 + radeon_fence_unref(>last_sync);
 + bo->last_sync = radeon_fence_ref(fence);
 + }
 + bo->last_user = parser->filp;
 +
 + if (!reloc->written)
continue;

radeon_fence_unref(>written);
 diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
 b/drivers/gpu/drm/radeon/radeon_gem.c
 index bfd7e1b..c73dbc1 100644
 --- a/drivers/gpu/drm/radeon/radeon_gem.c
 +++ b/drivers/gpu/drm/radeon/radeon_gem.c
 @@ -259,6 +259,7 @@ int radeon_gem_create_ioctl(struct drm_device *dev, 
 void *data,
r = radeon_gem_handle_lockup(rdev, r);
return r;
}
 + gem_to_radeon_bo(gobj)->last_user = filp;
r = drm_gem_handle_create(filp, gobj, );
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(gobj);
 diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
 b/drivers/gpu/drm/radeon/radeon_ttm.c
 index 76be612..a4f964f 100644
 ---

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

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

Christian K?nig  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #9 from Christian 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/20140815/6d46b131/attachment.html>

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

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

Kai  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Kai  ---
(In reply to comment #7)
> Created attachment 104563 [details] [review]
> Possible fix.
> 
> That patch does the trick for me, please test.

Yes, the patch works for me as well. Thank you!

Since you've already commited the patch
(<http://cgit.freedesktop.org/mesa/mesa/commit/?id=6fb42ee7a632e181160ac4be234b30e50a1b91d5>)
I don't think a Tested-by will be needed here anylonger.

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

Fence, timeline and android sync points

2014-08-15 Thread Thomas Hellstrom

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 as cmdbuf_ioctl do not give you 
>>> fence|syncpt
>>> you can not such thing cleanly in non hackish way.
>> Actually i915 can soon will do that that.
> So you will return fence|syncpoint with each cmdbuf_ioctl ?
>
>>> Sucks because you have a fence object per buffer object and thus overhead 
>>> grow
>>> with the number of objects. Not even mentioning fence lifetime issue.
>>>
>>> Sucks because sub-buffer allocation is just one of many tricks that can not 
>>> be
>>> achieved properly and cleanly with implicit sync.
>>>
>>> ...
>> Well I heard all those reasons and I'm well of aware of them. The
>> problem is that with current hardware the kernel needs to know for
>> each buffer how long it needs to be kept around since hw just can't do
>> page faulting. Yeah you can pin them but for an uma design that
>> doesn't go down well with folks.
> I am not thinking with fancy hw in mind, on contrary i thought about all
> this with the crappiest hw i could think of, in mind.
>
> Yes you can get rid of fence and not have to pin memory with current hw.
> What matter for unpinning is to know that all hw block are done using the
> memory. This is easily achievable with your beloved seqno. Have one seqno
> per driver (one driver can have different block 3d, video decoding, crtc,
> ...) each time a buffer is use as part of a command on one block inc the
> common seqno and tag the buffer with that number. Have each hw block write
> the lastest seqno that is done to a per block location. Now to determine
> is buffer is done compare the buffer seqno with the max of all the signaled
> seqno of all blocks.
>
> Cost 1 uint32 per buffer and simple if without locking to check status of
> a buffer.

Hmm?
The trivial and first use of fence objects in the linux DRM was
triggered by the fact that a
32-bit seqno wraps pretty quickly and a 32-bit solution just can't be
made robust.
Now a 64-bit seqno will probably be robust for forseeable future, but
when it comes to implement that on 32-bit hardware and compare it to a
simple fence object approach,

/Thomas

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

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

--- Comment #8 from Vladimir Ysikov  ---
ArchLinux x86-64; linux 3.16; mesa git; llvm svn; Radeon HD 7950

Is it still correct?

I have:

$ mplayer -benchmark -nosound -lavdopts threads=16
Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo gl  

BENCHMARKs: VC:   3.404s VO:  17.792s A:   0.000s Sys:   1.978s =   23.174s
BENCHMARK%: VC: 14.6908% VO: 76.7753% A:  0.% Sys:  8.5339% = 100.%

$ mplayer -benchmark -nosound -lavdopts threads=16
Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo xv

BENCHMARKs: VC:  10.609s VO:   3.479s A:   0.000s Sys:   1.867s =   15.955s
BENCHMARK%: VC: 66.4934% VO: 21.8045% A:  0.% Sys: 11.7021% = 100.%

$ mplayer -benchmark -nosound -lavdopts threads=16
Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau

BENCHMARKs: VC:   3.319s VO:  16.936s A:   0.000s Sys:   0.644s =   20.900s
BENCHMARK%: VC: 15.8826% VO: 81.0336% A:  0.% Sys:  3.0837% = 100.%

$ mplayer -benchmark -nosound -lavdopts threads=16
Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo null

BENCHMARKs: VC:  11.915s VO:   0.003s A:   0.000s Sys:   0.653s =   12.571s
BENCHMARK%: VC: 94.7809% VO:  0.0228% A:  0.% Sys:  5.1963% = 100.%

$ mplayer -benchmark -nosound -lavdopts threads=16
Planet_Earth_From_Pole_to_Pole_1080p_sample.mkv -vo vdpau -vc ffh264vdpau

BENCHMARKs: VC:   7.402s VO:  13.679s A:   0.000s Sys:   0.692s =   21.773s
BENCHMARK%: VC: 33.9957% VO: 62.8252% A:  0.% Sys:  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

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

--- Comment #10 from charlie <407883775 at qq.com> ---
Created attachment 104657
  --> https://bugs.freedesktop.org/attachment.cgi?id=104657=edit
detail

Our system PAGE_SIZE is 8k, but the GPU PAGE_SIZE is 4k. I have changed the
mesa radeonsi driver memory 8K alignment . So, the virtual address allocate
conflict disappear . But the new problem is come out .
The log message is :
[ 3574.344456] radeon :01:00.0: GPU fault detected: 147 0x01424802
[ 3574.344481] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x0002020A
[ 3574.344499] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x02048002
[ 3574.344518] VM fault (0x02, vmid 1) at page 131594, read from TC (72)
[ 3574.344543] radeon :01:00.0: GPU fault detected: 147 0x01424802
[ 3574.344563] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[ 3574.344583] radeon :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x
[ 3574.344601] VM fault (0x00, vmid 0) at page 0, read from unknown (0)

what's fault with it? The GPU cannot detected?

-- 
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/0b85af36/attachment.html>

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

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

--- Comment #5 from pavol at klacansky.com ---
I have got new mesa from PPA and problem seems to be gone. How can I find exact
commit fixing this, please?

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

[Bug 82431] Garbled screen on boot

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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)

2014-08-15 Thread Dave Airlie


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 (2014-08-14 
11:14:29 -0600)

are available in the git repository at:


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

for you to fetch changes up to 251964845fbf539781dd2c6406cb2ba1bf9eddd0:

  drm/doc: Refer to proper source file (2014-08-15 09:50:41 +1000)


Alexandre Courbot (2):
  drm/nouveau/gk20a: add LTC device
  drm/nouveau/platform: fix compilation error

Ben Skeggs (9):
  drm/nouveau/nvif: fix a number of notify thinkos
  drm/nouveau: kill unused variable warning if !__OS_HAS_AGP
  drm/nouveau/bar: behave better if ioremap failed
  drm/nvc0-/fb/ram: fix use of non-existant ram if partitions aren't uniform
  drm/nouveau/ltc: fix tag base address getting truncated if above 4GiB
  drm/nouveau/nvif: return null pointers on failure, in addition to ret != 0
  drm/gf100-/gr: fix -ENOSPC detection when allocating zbc table entries
  drm/nouveau/nvif: fix dac load detect method definition
  drm/nouveau: warn if we fail to re-pin fb on resume

Dave Airlie (1):
  Merge branch 'linux-3.17' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

Fengguang Wu (1):
  drm/nouveau/kms: nouveau_fbcon_accel_fini can be static

Thierry Reding (1):
  drm/doc: Refer to proper source file

 Documentation/DocBook/drm.tmpl |  2 +-
 drivers/gpu/drm/nouveau/core/core/client.c |  4 +--
 drivers/gpu/drm/nouveau/core/engine/device/nve0.c  |  1 +
 drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c   |  6 +
 drivers/gpu/drm/nouveau/core/include/core/client.h |  2 +-
 drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 14 ---
 drivers/gpu/drm/nouveau/core/subdev/fb/ramnvc0.c   |  4 +--
 drivers/gpu/drm/nouveau/core/subdev/ltc/gf100.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c   |  3 +--
 drivers/gpu/drm/nouveau/nouveau_display.c  |  4 ++-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c|  4 +--
 drivers/gpu/drm/nouveau/nouveau_platform.c |  3 ++-
 drivers/gpu/drm/nouveau/nvif/class.h   |  4 +--
 drivers/gpu/drm/nouveau/nvif/notify.c  | 29 +++---
 drivers/gpu/drm/nouveau/nvif/object.c  |  4 ++-
 15 files changed, 58 insertions(+), 28 deletions(-)

[Bug 82431] Garbled screen on boot

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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 enabled again on
those asics in 3.17.

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

[Bug 82431] Garbled screen on boot

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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 passed to the kernel. 

GRUB_GFXPAYLOAD_LINUX=keep (nor text) did make any difference.

Can this be permanently fixed for everyone affected?

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

[Bug 82431] Garbled screen on boot

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #2 from Alex Deucher  ---
I doubt that commit is the problematic one.  However, you can revert to the
previous behavior by passing radeon.dpm=1 on the kernel command line in grub.

This looks like a duplicate of:
https://bugs.freedesktop.org/show_bug.cgi?id=43655
Does your grub config have GRUB_GFXPAYLOAD_LINUX=keep in it?  If so, does
removing that help?

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

[Bug 82431] Garbled screen on boot

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #1 from Fede  ---
Created attachment 146691
  --> https://bugzilla.kernel.org/attachment.cgi?id=146691=edit
Image of issue

At times only a thin dotted line can be seen on the top, other times the
content is displayed flickering, starting from the center of the screen and
wrapped around the screen from right to left. When it does not flicker, the
screen looks as shown in the attachment.

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

[Bug 82431] New: Garbled screen on boot

2014-08-15 Thread bugzilla-dae...@bugzilla.kernel.org

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
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: fedevx at yahoo.com
Regression: No

When using any kernel higher than 3.13.6-20 (all the way to 3.16), my Toshiba
M840's screen gets garbled after Grub (grub itself is fine).

In particular, because my whole drive is encrypted, I see the garbled screen
when the prompt for the encryption key comes up.

I have the issue with my OpenSUSE installation and when booting off Archlinux's
installer.

I'm not sure if this is relevant but this happens on UEFI, if I change the
setting back to BIOS compatibility, at least on the Archlinux's installer, the
issue goes away. I can't test this on OpenSUSE since it is already set to UEFI
and will not boot on BIOS compatibility mode.

The issue has quite an impact since I can't bootup in a usable way, any Linux
distribution with a kernel newer than the one stated above.

I did a kernel bisect and found the below commit to be the cause of the issue:

[919cf555c04e16dafb1fba56904eb23889a812c3] drm/radeon: disable dpm on BTC
919cf555c04e16dafb1fba56904eb23889a812c3 is the first bad commit
commit 919cf555c04e16dafb1fba56904eb23889a812c3
Author: Alex Deucher 
Date:   Sat Jan 11 10:55:55 2014 -0500

drm/radeon: disable dpm on BTC

Still unstable on some boards.

Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=73053
https://bugzilla.kernel.org/show_bug.cgi?id=68571

Signed-off-by: Alex Deucher 
Cc: 3.13  # 3.13

:04 04 c03cf693d8be0e49e0b431b968c4934324344d57
f4fa27f78f5ff03216036f8bcdc3978b274b812f M  drivers

Thanks!


Details about my GFX card:

21: PCI 100.0: 0300 VGA compatible controller (VGA) 
  [Created at pci.319]
  Unique ID: VCu0.dkF2+KIVH8C
  Parent ID: vSkL.zuRwVyuZRN1
  SysFS ID: /devices/pci:00/:00:01.0/:01:00.0
  SysFS BusID: :01:00.0
  Hardware Class: graphics card
  Model: "ATI VGA compatible controller"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x6840 
  SubVendor: pci 0x1179 "Toshiba America Info Systems"
  SubDevice: pci 0xfb81 
  Driver: "radeon"
  Driver Modules: "drm"
  Memory Range: 0xb000-0xbfff (ro,non-prefetchable)
  Memory Range: 0xc000-0xc001 (rw,non-prefetchable)
  I/O Ports: 0x3000-0x3fff (rw)
  Memory Range: 0xc004-0xc005 (ro,non-prefetchable,disabled)
  IRQ: 43 (76519 events)
  Module Alias: "pci:v1002d6840sv1179sdFB81bc03sc00i00"
  Driver Info #0:
Driver Status: radeon is active
Driver Activation Cmd: "modprobe radeon"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #9 (PCI bridge)
---

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

[Bug 82455] Failed to allocate virtual address for buffer

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

--- Comment #9 from charlie <407883775 at qq.com> ---
Created attachment 104647
  --> https://bugs.freedesktop.org/attachment.cgi?id=104647=edit
detail

dmesg

-- 
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/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/~agd5f/linux drm-fixes-3.17

for you to fetch changes up to c8ad8b563c7e724e2fedc3aee5bcbd401668474c:

  drm/radeon: Remove duplicate include from Makefile (2014-08-15 00:58:20 -0400)


Alex Deucher (3):
  drm/radeon: add bapm module parameter
  drm/radeon: use pfp for all vm_flush related updates
  drm/radeon/dpm: select the appropriate vce power state for KV/KB/ML

Andreas Ruprecht (1):
  drm/radeon: Remove duplicate include from Makefile

Dan Carpenter (1):
  drm/radeon: add a check for allocation failure (v2)

Michel D?nzer (1):
  drm/radeon: Always flush VM again on < CIK

Oleg Chernovskiy (1):
  drm/radeon: Add missing lines to ci_set_thermal_temperature_range

Pali Roh?r (1):
  drm/radeon: Add ability to get and change dpm state when radeon PX card 
is turned off

 drivers/gpu/drm/radeon/Makefile  |  2 +-
 drivers/gpu/drm/radeon/ci_dpm.c  |  3 +++
 drivers/gpu/drm/radeon/cik.c |  8 
 drivers/gpu/drm/radeon/kv_dpm.c  | 11 +++
 drivers/gpu/drm/radeon/radeon.h  |  1 +
 drivers/gpu/drm/radeon/radeon_drv.c  |  4 
 drivers/gpu/drm/radeon/radeon_pm.c   | 16 ++--
 drivers/gpu/drm/radeon/radeon_vm.c   |  8 +++-
 drivers/gpu/drm/radeon/si.c  |  4 ++--
 drivers/gpu/drm/radeon/trinity_dpm.c | 24 +++-
 10 files changed, 50 insertions(+), 31 deletions(-)

Fence, timeline and android sync points

On Thu, Aug 14, 2014 at 9:15 PM, Jerome Glisse  wrote:
> Yes preemption and gpu scheduling would break such scheme, but my point is
> that when you have such gpu you want to implement a proper solution. Which
> of course require quite some work accross the stack. So the past can live
> on but the future needs to get its acts together.
>
>> The other problem is that the Linux Desktop I don't seem to care about
>> any more kinda relies on implicit syncing right now, so we better keep
>> that working fairly well. Of course we could dream up a shiny new
>> world where all of the Linux desktop does explicit syncing, but that
>> world doesn't exist right now. I mean really if you want to right away
>> throw implicit syncing overboard that doesn't bode well for the
>> current linux desktop.
>
> Again i fail at expressing myself. I am saying throw things over board,
> i am well aware of the current reliance on implicit fencing. I am saying
> if fence wants to be this new thing that should allow to do explicit
> fencing in the future than it better be done correctly in the first place.
>
>> So I don't understand all the implicit syncing bashing. It's here, and
>> it'll stay for a while longer whether you like it or not ...
>
> I am saying this is where we are and it sucks for a number of reasons,
> then looking at fence and by looking at fence i am saying this try to
> go in the right direction but do crazy things that i am convince we
> will regret. In other word if we ever get to the explicit fence better
> starts on the right path with the right tool. Moreover i am saying that
> this can be done without breaking implicit sync we have today.
>
>> Of course that doesn't mean we (intel here) won't support explicit
>> syncing too, and I really don't see a conflict here when mixing and
>> matching these two approaches.
>
> Again i fail to express myself. I am not saying there is conflict. I
> am saying better take a path which allow to go full way with explicit
> fencing while still allowing a less optimal use for an implicit sync
> model.
>
> My point is the fence code proposed here, keeps the worst thing about
> implicit fencing we have today. This can be done differently, in what
> i believe to be better way. And this different approach stills allow
> to have have implicit sync for existing userspace.

Well the problem is I can't wait for that shiny new world to finally
arrive, I kinda have to work with what's there. Which is ugly, messy,
but that's how it is.

So I'm not going to throw away piles of code just because it's ugly
and combining it with the new world is a major pain. Instead I'll
gobble down the ugly, throw testcases at the problem to make sure it
works and ship this frankenstein monster.

If you actually look at development stats we've completely rewritten
i915.ko in the past 2 years (again) and will likely continue for a
while. But we do that with small (tiny) steps and not with big jumps,
because with the current pace and ongoing projects that's plainly too
disruptive. So I envy you if you can do this with radeon, but there's
no way I can do that with i915, I just have to live with it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Fence, timeline and android sync points

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.

Yeah well except it doesn't and that's why we switch to full blown
fence objects internally instead of smacking seqno values all over the
place. At least in i915 because I have seen what this "simple"
solution looks like if you throw all the complexities into the bin and
mix it well.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Fence, timeline and android sync points