[RFC] Explicit synchronization for Nouveau

[Daniel Vetter]

On Thu, Oct 02, 2014 at 05:59:51PM +0300, Lauri Peltonen wrote:
> +Rom who seems to be presenting about mainlining android sync at linux 
> plumbers

Also add Greg KH as fyi that we're working on de-stage one of the android
subsystems.

> On Wed, Oct 01, 2014 at 05:58:52PM +0200, Maarten Lankhorst wrote:
> > You could neuter implicit fences by always attaching the fences as
> > shared when explicit syncing is used. This would work correctly with
> > eviction, and wouldn't cause any unneeded syncing. :)
> 
> Yes, that will probably work!  So, just to reiterate that I understood you and
> Daniel correctly:
> 
> - de-stage sync_fence and it's user space API (the tedious part)
> - add dma-buf ioctls for extracting and attaching explicit fences
> - Nouveau specific: allow flagging gem buffers for explicit sync
>   - do not check pre-fences from explicitly synced buffers at submit 
>   - continue to attach a shared fence after submit so that pinning and
> unmapping continue to work

- Have explicit in/out fences for the pushbuf ioctl is missing I
  guess in this step?

I also think we need some kind of demonstration vehicle using nouveau to
satisfy Dave Airlie's open-source userspace requirements for new
interfaces. Might be good to chat with him to make sure we have that
covered (and how much needs to be there really).

> Then working sets and getting rid of locking all buffers individually 
> can be dealt with later as an optimization.

Yeah, sounds like a good plan.

> On Wed, Oct 01, 2014 at 07:27:21PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 01, 2014 at 06:14:16PM +0300, Lauri Peltonen wrote:
> > > Implicit fences attached to individual buffers are one way for residency
> > > management.  Do you think a working set based model could work in the DRM
> > > framework?  For example, something like this:
> > > 
> > > - Allow user space to create "working set objects" and associate buffers 
> > > with
> > >   them.  If the user space doesn't want to manage working sets 
> > > explicitly, it
> > >   could also use an implicit default working set that contains all 
> > > buffers that
> > >   are mapped to the channel vm (on Android we could always use the default
> > >   working set since we don't need to manage residency).  The working sets 
> > > are
> > >   initially marked as dirty.
> > > - User space tells which working sets are referenced by each work 
> > > submission.
> > >   Kernel locks these working sets, pins all buffers in dirty working 
> > > sets, and
> > >   resets the dirty bits.  After kicking off work, kernel stores the fence 
> > > to
> > >   the _working sets_, and then releases the locks (if an implicit default
> > >   working set is used, then this would be roughly equivalent to storing a 
> > > fence
> > >   to channel vm that tells "this is the last hw operation that might have
> > >   touched buffers in this address space").
> > > - If swapping doesn't happen, then we just need to check the working set 
> > > dirty
> > >   bits at each submit.
> > > - When a buffer is swapped out, all working sets that refer to it need to 
> > > be
> > >   marked as dirty.
> > > - When a buffer is swapped out or unmapped, we need to wait for the 
> > > fences from
> > >   all working sets that refer to the buffer.
> > > 
> > > Initially one might think of working sets as a mere optimization - we now 
> > > need
> > > to process a few working sets at every submit instead of many individual
> > > buffers.  However, it makes a huge difference because of fences: fences 
> > > that
> > > are attached to buffers are used for implicitly synchronizing work across
> > > different channels and engines.  They are in the performance critical 
> > > path, and
> > > we want to carefully manage them (that's the idea of explicit 
> > > synchronization).
> > > The working set fences, on the other hand, would only be used to 
> > > guarantee that
> > > we don't swap out or unmap something that the GPU might be accessing.  We 
> > > never
> > > need to wait for those fences (except when swapping or unmapping), so we 
> > > can be
> > > conservative without hurting performance.
> > 
> > Yeah, within the driver (i.e. for private objects which are never exported
> > to dma_buf) we can recently do stuff like this. And your above idea is
> > roughly one of the things we're tossing around for i915.
> > 
> > But the cool stuff with drm is that cmd submission is driver-specific, so
> > you can just go wild with nouveau. Of course you have to coninvce the
> > nouveau guys (and also have open-source users for the new interface).
> > 
> > For shared buffers I think we should stick with the implicit fences for a
> > while simply because I'm not sure whether it's really worth the fuzz. And
> > reworking all the drivers and dma-buf for some working sets is a lot of
> > fuzz ;-) Like Maarten said you can mostly short-circuit the implicit
> > fencing by only attaching shared fences.
> 
> Yes, I'll try to do that.
> 
> 
> > 

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

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

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

--- Comment #9 from Jos? Su?rez  ---
I have been trying linux 3.16 with the packet0 patch and after some testing I
haven't got any Packet0 message in the dmesg log. So I guess it must be related
to the 3.17 rc's. I don't remember getting similar crashes just by watching
youtube videos in firefox with previous kernels.

I will try to build 3.17 rc6 (which was the version that gave the Packet0 logs
and system hangs) with the Packet 0 patch and report back.

@Alexandre: Can you try linux 3.16 and see if it works properly for you?

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

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #4 from Alex Deucher  ---
Can you narrow down when the problem started?  Even better, can you bisect?

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

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

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

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

Zermond  changed:

   What|Removed |Added

   Tree|Fedora  |Mainline

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

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

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

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

--- Comment #3 from Zermond  ---
Created attachment 152271
  --> https://bugzilla.kernel.org/attachment.cgi?id=152271=edit
uname-a with working kernel

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

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

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

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

--- Comment #2 from Zermond  ---
Created attachment 152261
  --> https://bugzilla.kernel.org/attachment.cgi?id=152261=edit
lspci

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

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

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

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

--- Comment #1 from Zermond  ---
Created attachment 152251
  --> https://bugzilla.kernel.org/attachment.cgi?id=152251=edit
dmesg

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

[Bug 85491] New: radeon 0000:01:00.0: Fatal error during GPU init

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

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

Bug ID: 85491
   Summary: radeon :01:00.0: Fatal error during GPU init
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16.3-200.fc20.x86_64
  Hardware: All
OS: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: zermond at gmail.com
Regression: No

Created attachment 152241
  --> https://bugzilla.kernel.org/attachment.cgi?id=152241=edit
journalctl

hello,


if I want upgrade kernel 3.11.* to 3.16.* I have subj problems (radeon
:01:00.0: Fatal error during GPU init). With kernel 3.11.* all working.


I attached systemctl --system (last booting with kernel 3.16*), uname -a,
dmesg, lspci

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

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #77 from Andy Furniss  ---
(In reply to Christoph Haag from comment #76)
> (In reply to Andy Furniss from comment #75)
> 
> > It would be useful to know if Elemental also worked with 3.17-rc7.
> 
> It's stuttering quite severely, but it feels more like "normal" performance
> drops and I don't think it completely hangs like in the videos I made before.
> 
> I actually tried it for the first time in months because in the past it hung
> the gpu and the operating system completely with gpu faults I think. Today I
> ran it for the first time without any severe problems, so radeonsi is
> definitely making good progress!

Ok, I'm going to open a new bug for this one when I have time to test more.

I can get the behavior you see, but only on the last kernel with the old
firmware I have installed, anything more recent including current agd5f 3.17
fixes gets long pauses for me.

What is your card?

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

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

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

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

--- Comment #44 from Chernovsky Oleg  ---
(In reply to Alex Deucher from comment #40)
> I found some time over the last couple of weekends to write up some
> preliminary patches that should point you in the right direction; I just
> need to run them by the IP team to make sure they are ok to release.  I'd
> like to avoid including reverse engineered stuff in the driver as it's a lot
> harder for us to maintain.

Alex, just reminding you of this bug, did the patch you mentioned passed the
review?
I'm inly waiting :)

-- 
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/20141002/17c26de1/attachment.html>

[PATCH v6 2/2] drm/i2c:tda998x: Use the HDMI audio CODEC

[Jean-Francois Moine]

On Wed, 1 Oct 2014 17:05:32 +0300
Jyri Sarha  wrote:

> > case AFMT_I2S:
>  >reg_write(priv, REG_MUX_AP, MUX_AP_SELECT_I2S);
>  >clksel_aip = AIP_CLKSEL_AIP_I2S;
>  >clksel_fs = AIP_CLKSEL_FS_ACLK;
>  > -  cts_n = CTS_N_M(3) | CTS_N_K(3);
>  > +
>  > +  /* with I2S input, the CTS_N predivider depends on
>  > +   * the sample width */
>  > +  switch (priv->audio_sample_format) {
>  > +  case SNDRV_PCM_FORMAT_S16_LE:
>  > +  cts_n = CTS_N_M(3) | CTS_N_K(1);
>  > +  break;
>  > +  case SNDRV_PCM_FORMAT_S24_LE:
>  > +  cts_n = CTS_N_M(3) | CTS_N_K(2);
>  > +  break;
>  > +  default:  
> 
> Setting the default here does not really help, because
> priv->audio_sample_format is initialized to SNDRV_PCM_FORMAT_S24_LE in
> tda998x_encoder_set_config(). But I am Ok with the default being
> changed for 24 bit samples on i2s interface.
> 
>  > +  case SNDRV_PCM_FORMAT_S32_LE:
>  > +  cts_n = CTS_N_M(3) | CTS_N_K(3);
>  > +  break;
>  > +  }

I looked again at the original driver and they set K = 1 for 16 bits
and K = 3 for 24 or 32 bits.

Anyway, letting K = 3 for 16 bits works for me, so, I will not change
this code in the next version.

Thanks.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH v6 2/2] drm/i2c:tda998x: Use the HDMI audio CODEC

[Jean-Francois Moine]

On Wed, 1 Oct 2014 15:23:41 +0100
Russell King - ARM Linux  wrote:

> I would prefer this structure to stay here, as code above this point should
> have no business knowing how these are packaged together.  I would suggest
> either:
> 
> - moving the audio codec code below this point, or
> - storing struct tda998x_priv in the device private pointer, and
>   converting it to struct tda998x_priv2 via container_of() where
>   necessary below this point.

The second option seems easier for use as a slave encoder.

Thanks for all your remarks. I will send an other version.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[PATCH] drm/exynos: fix vblank handling during dpms off

[Inki Dae]

On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
> Hi Andrzej,
> 
> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
>> The patch disables vblanks during dpms off only if pagefilp has
>> not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
>> It fixes issue with page_flip ioctl not being able to acquire vblank counter.
> 
> This problem isn't related with pageflip, it just causes from
> 7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
> drm_vblank_get() after drm_vblank_off()).
> 
> We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
> after the commit .
> 
> How about below patch?

Thanks you Joonyoung and Andrzej,

drm_vblank_on/off() are legacy api so it would be better to use
drm_vblank_crtc_on/off functions instead.

And drm_vblank_crtc_off() makes sure that the latest vblank frame count
is stored and restored by drm_vblank_crtc_on() again. So my opinion is,

static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int mode)
{
[snip]

if (mode > DRM_MODE_DPMS_ON) {
/* wait for the completion of page flip. */
if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
!atomic_read(_crtc->pending_flip),
HZ/20))
atomic_set(_crtc->pending_flip, 0);
drm_crtc_vblank_off(crtc);  //<- store the latest 
vblank frame count.
} else {
drm_crtc_vblank_on(crtc);   //<- restore the vblank 
frame count.
}

[snip]
}


Tested and worked well with above patch. How about it?

Thanks,
Inki Dae

> 
>>From 6de01473746af225c688ee430123001d57d9af2a Mon Sep 17 00:00:00 2001
> From: Joonyoung Shim 
> Date: Thu, 2 Oct 2014 17:48:27 +0900
> Subject: [PATCH] drm/exynos: use drm_vblank_on()
> 
> We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
> after the commit 7ffd7a68511c ("drm: Always reject drm_vblank_get()
> after drm_vblank_off()"). If not, drm_vblank_get() will be failed
> always after drm_vblank_off().
> 
> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 8e38e9f..dfa209a 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -71,7 +71,6 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
> mode)
>   !atomic_read(_crtc->pending_flip),
>   HZ/20))
>   atomic_set(_crtc->pending_flip, 0);
> - drm_vblank_off(crtc->dev, exynos_crtc->pipe);
>   }
>  
>   if (manager->ops->dpms)
> @@ -90,6 +89,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>   struct exynos_drm_manager *manager = exynos_crtc->manager;
>  
> + drm_vblank_on(crtc->dev, exynos_crtc->pipe);
>   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
>  
>   exynos_plane_commit(crtc->primary);
> @@ -177,10 +177,12 @@ static int exynos_drm_crtc_mode_set_base(struct 
> drm_crtc *crtc, int x, int y,
>  
>  static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
>  {
> + struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
>   struct drm_plane *plane;
>   int ret;
>  
>   exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
> + drm_vblank_off(crtc->dev, exynos_crtc->pipe);
>  
>   drm_for_each_legacy_plane(plane, >dev->mode_config.plane_list) {
>   if (plane->crtc != crtc)
> 

FOSDEM15: Graphics DevRoom: call for speakers.

[Luc Verhaegen]

Hi,

At FOSDEM on the 31st of january and the 1st of February 2015, there 
will be another graphics DevRoom. URL: https://fosdem.org/2015/

The focus of this DevRoom is of course the same as last year, namely:
* Graphics drivers: from display to media to 3d drivers, both in kernel 
  or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa...
* Input drivers: kernel and userspace.
* Windowing systems: X, Wayland, Mir, directFB, ...
* Even colour management and other areas which i might have overlooked 
  above are accepted.

Slots are 50 minutes long, and scheduled hourly. This partly to avoid 
confusion and people running all over the place all the time. As a 
speaker, you do not have to fill your whole hour, gaps are never wasted 
time.

Slots will be handed out on a first come, first serve basis. The best 
slots will go to those who apply the earliest. The amount of slots is 
currently not known yet, but i expect there to be around 16 available (8 
on each day), so act quickly.

Talk Submission:


Like last year, the pentabarf system will be used for talk submission. 
It is not perfect from a devroom organizer and talk submitters usability 
point-of-view, but the fosdem organizers are working on it. It is 
however workable and it ended up working out pretty well last year.

https://penta.fosdem.org/submission/FOSDEM15

Remember that FOSDEM is not like XDC, it's not some 50 odd people 
meeting with a sliding schedule which only gets filled out on the last 
day. Upwards of 8000 people are visiting this event, and most of them 
get a printed booklet or use the schedule on the FOSDEM website or an 
app for their phone to figure out what to watch or participate in next. 
So please put some effort in your talk submission and details.

Since this an open source community event, please refrain from turning 
in a talk that is a pure corporate or product commercial. Also, if you 
are unsure on whether you can come or not (this is FOSDEM, why are you 
not there anyway?), please wait with submitting your talk. Submitting a 
talk and then not turning up because you could not be bothered is a 
sure-fire way to get larted and then to never be allowed to talk again.

As for deadlines, i hope to have a pretty much complete schedule between 
christmas and the new year. The rockhard printed schedule deadline is 
probably January 9th, after that you will not be featured in the booklet 
and you will have a lot less visitors. I will hopefully be able to lock 
down entries and descriptions after that date.

Don't count on this deadline: first come first serve! There are perhaps 
only 16 slots. And the worst slots will be assigned to those who come 
last. Do you really want to talk on saturday at 10:00 when people are 
still in zombie mode after the beer event, if they are there at all?

Use your account from last year, so you can try to recycle some of your 
data from last year. If you have forgotten your password, then you can 
reset it here: https://penta.fosdem.org/user/forgot_password

Necessary information:
--

Below is a list of what i need to see filled in when you apply for a 
devroom before i consider it a valid submission. Remember: first come, 
first serve. The best slots are for the earliest submissions and there 
are only around 16 slots.

On your personal page:
* General:
  * First and last name
  * Nickname
  * Image
* Contact:
  * email
  * mobile number (this is a very hard requirement as there will be no 
other reliable form of emergency communication on the day)
* Description:
  * Abstract
  * Description

Create an event:
* On the General page:
  * Event title
  * Event subtitle.
  * Track: Graphics Devroom
  * Event type: Lecture (talk) or Meeting (BoF)
* Persons:
  * Add yourself as speaker.
* Description:
  * Abstract:
  * Full Description
* Links:
  * Add relevant links.

Everything else can be ignored or will be filled in by me or the FOSDEM 
organizers.

That's about it. Hope to see you all at FOSDEM :)

Luc Verhaegen.

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl

[Inki Dae]

On 2014? 10? 02? 08:47, Joonyoung Shim wrote:
> Hi Tomasz,
> 
> On 10/02/2014 12:13 AM, Tomasz Figa wrote:
>> Hi Inki,
>>
>> On 17.09.2014 15:48, Inki Dae wrote:
>>> This interface and relevant codes aren't used anymore.
>>>
>>
>> Hmm, I might be missing something, but after removing this IOCTL, how do
>> we obtain an offset to pass to mmap()?
> 
> There is DRM_IOCTL_MODE_MAP_DUMB, it can get mmap offset before mmap and
> the offset is passed via mmap.

Exactly. That will lead us to more generic world.

Thanks,
Inki Dae

> 
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[PATCH 2/2] drm/exynos: use drm generic mmap interface

[Inki Dae]

On 2014? 10? 01? 22:17, Tomasz Figa wrote:
> Hi Inki,
> 
> On 17.09.2014 15:48, Inki Dae wrote:
>> This patch removes DRM_EXYNOS_GEM_MMAP ictrl feature specific
>> to Exynos drm and instead uses drm generic mmap.
> 
> It looks like libdrm_exynos is still using DRM_EXYNOS_GEM_MMAP, but this
> patch just removes it. This basically means that any application using
> it is now broken. Do you have any plans to fix this?
> 

Hi Tomasz,

Yes, of course.

We will fix it soon. For this, I mentioned earlier,
http://web.archiveorange.com/archive/v/hhSc574WhqJAKgdBq7KL

Thanks,
Inki Dae

> Best regards,
> Tomasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #76 from Christoph Haag  ---
(In reply to Andy Furniss from comment #75)

> It would be useful to know if Elemental also worked with 3.17-rc7.

It's stuttering quite severely, but it feels more like "normal" performance
drops and I don't think it completely hangs like in the videos I made before.

I actually tried it for the first time in months because in the past it hung
the gpu and the operating system completely with gpu faults I think. Today I
ran it for the first time without any severe problems, so radeonsi is
definitely making good progress!

-- 
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/20141002/09ac4c9e/attachment.html>

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #75 from Andy Furniss  ---
(In reply to Christoph Haag from comment #74)
> Well.
> 
> I have said that I used drm-next-3.18 and had these hangs.
> When I applied
> http://lists.freedesktop.org/archives/mesa-dev/2014-August/066746.html it
> did not help.
> 
> Now I am using 3.17-rc7 with that mesa patch and I do not see these hangs
> anymore. Or maybe they are these very short stutters.
> 
> Sorry if drm-next-3.18 behavior is not relevant here.
> 
> As for the num bytes moved: Does the HUD graph only accumulate everything
> that happened in the hang? If so, then the hundreds of megabytes still seem
> more than normal and the used graphs definitely show change before and after
> the hangs. Whatever you make of that...
> 
> 
> CONFIG_CMA is not enabled on either kernel.
> 
> Indeed, there's less moving of data with the rc kernel I think.
> For comparison: https://www.youtube.com/watch?v=mFaqHGle9Hg

It would be useful to know if Elemental also worked with 3.17-rc7.

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

[RFC] Explicit synchronization for Nouveau

[Lauri Peltonen]

+Rom who seems to be presenting about mainlining android sync at linux plumbers


On Wed, Oct 01, 2014 at 05:58:52PM +0200, Maarten Lankhorst wrote:
> You could neuter implicit fences by always attaching the fences as
> shared when explicit syncing is used. This would work correctly with
> eviction, and wouldn't cause any unneeded syncing. :)

Yes, that will probably work!  So, just to reiterate that I understood you and
Daniel correctly:

- de-stage sync_fence and it's user space API (the tedious part)
- add dma-buf ioctls for extracting and attaching explicit fences
- Nouveau specific: allow flagging gem buffers for explicit sync
  - do not check pre-fences from explicitly synced buffers at submit 
  - continue to attach a shared fence after submit so that pinning and
unmapping continue to work

Then working sets and getting rid of locking all buffers individually 
can be dealt with later as an optimization.


On Wed, Oct 01, 2014 at 07:27:21PM +0200, Daniel Vetter wrote:
> On Wed, Oct 01, 2014 at 06:14:16PM +0300, Lauri Peltonen wrote:
> > Implicit fences attached to individual buffers are one way for residency
> > management.  Do you think a working set based model could work in the DRM
> > framework?  For example, something like this:
> > 
> > - Allow user space to create "working set objects" and associate buffers 
> > with
> >   them.  If the user space doesn't want to manage working sets explicitly, 
> > it
> >   could also use an implicit default working set that contains all buffers 
> > that
> >   are mapped to the channel vm (on Android we could always use the default
> >   working set since we don't need to manage residency).  The working sets 
> > are
> >   initially marked as dirty.
> > - User space tells which working sets are referenced by each work 
> > submission.
> >   Kernel locks these working sets, pins all buffers in dirty working sets, 
> > and
> >   resets the dirty bits.  After kicking off work, kernel stores the fence to
> >   the _working sets_, and then releases the locks (if an implicit default
> >   working set is used, then this would be roughly equivalent to storing a 
> > fence
> >   to channel vm that tells "this is the last hw operation that might have
> >   touched buffers in this address space").
> > - If swapping doesn't happen, then we just need to check the working set 
> > dirty
> >   bits at each submit.
> > - When a buffer is swapped out, all working sets that refer to it need to be
> >   marked as dirty.
> > - When a buffer is swapped out or unmapped, we need to wait for the fences 
> > from
> >   all working sets that refer to the buffer.
> > 
> > Initially one might think of working sets as a mere optimization - we now 
> > need
> > to process a few working sets at every submit instead of many individual
> > buffers.  However, it makes a huge difference because of fences: fences that
> > are attached to buffers are used for implicitly synchronizing work across
> > different channels and engines.  They are in the performance critical path, 
> > and
> > we want to carefully manage them (that's the idea of explicit 
> > synchronization).
> > The working set fences, on the other hand, would only be used to guarantee 
> > that
> > we don't swap out or unmap something that the GPU might be accessing.  We 
> > never
> > need to wait for those fences (except when swapping or unmapping), so we 
> > can be
> > conservative without hurting performance.
> 
> Yeah, within the driver (i.e. for private objects which are never exported
> to dma_buf) we can recently do stuff like this. And your above idea is
> roughly one of the things we're tossing around for i915.
> 
> But the cool stuff with drm is that cmd submission is driver-specific, so
> you can just go wild with nouveau. Of course you have to coninvce the
> nouveau guys (and also have open-source users for the new interface).
> 
> For shared buffers I think we should stick with the implicit fences for a
> while simply because I'm not sure whether it's really worth the fuzz. And
> reworking all the drivers and dma-buf for some working sets is a lot of
> fuzz ;-) Like Maarten said you can mostly short-circuit the implicit
> fencing by only attaching shared fences.

Yes, I'll try to do that.


> In case you're curious: The idea is to have a 1:1 association between
> ppgtt address spaces and what you call the working set above, to implement
> the buffer svm model in ocl2. Mostly because we expect that applications
> won't get the more fine-grained buffer list right anyway. And this kind of
> gang-scheduling of working set sizes should be more efficient for the
> usual case where everything fits.

If I understood correctly, this would be exactly the same as what I called the
"default working set" above.  On Android we don't care much about finer grained
working sets either, because of UMA and no swapping.


> > > Imo de-staging the android syncpt stuff needs to happen first, before 
> > > drivers
> > > can use it. 

[PATCH] drm/exynos: fix vblank handling during dpms off

[Joonyoung Shim]

Hi Andrzej,

On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
> The patch disables vblanks during dpms off only if pagefilp has
> not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
> It fixes issue with page_flip ioctl not being able to acquire vblank counter.

This problem isn't related with pageflip, it just causes from
7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
drm_vblank_get() after drm_vblank_off()).

We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit .

How about below patch?

>From 6de01473746af225c688ee430123001d57d9af2a Mon Sep 17 00:00:00 2001
From: Joonyoung Shim 
Date: Thu, 2 Oct 2014 17:48:27 +0900
Subject: [PATCH] drm/exynos: use drm_vblank_on()

We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
after the commit 7ffd7a68511c ("drm: Always reject drm_vblank_get()
after drm_vblank_off()"). If not, drm_vblank_get() will be failed
always after drm_vblank_off().

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 8e38e9f..dfa209a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -71,7 +71,6 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, int 
mode)
!atomic_read(_crtc->pending_flip),
HZ/20))
atomic_set(_crtc->pending_flip, 0);
-   drm_vblank_off(crtc->dev, exynos_crtc->pipe);
}

if (manager->ops->dpms)
@@ -90,6 +89,7 @@ static void exynos_drm_crtc_commit(struct drm_crtc *crtc)
struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct exynos_drm_manager *manager = exynos_crtc->manager;

+   drm_vblank_on(crtc->dev, exynos_crtc->pipe);
exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_ON);

exynos_plane_commit(crtc->primary);
@@ -177,10 +177,12 @@ static int exynos_drm_crtc_mode_set_base(struct drm_crtc 
*crtc, int x, int y,

 static void exynos_drm_crtc_disable(struct drm_crtc *crtc)
 {
+   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
struct drm_plane *plane;
int ret;

exynos_drm_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
+   drm_vblank_off(crtc->dev, exynos_crtc->pipe);

drm_for_each_legacy_plane(plane, >dev->mode_config.plane_list) {
if (plane->crtc != crtc)
-- 
1.9.1

Thanks.

> 
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Inki,
> 
> This is fix (or just workaround) of the problem you have reported.
> Please carefully verify it, as I am not familiar with pageflip code.
> 
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 8e38e9f..57fa94d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -69,9 +69,10 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, 
> int mode)
>   /* wait for the completion of page flip. */
>   if (!wait_event_timeout(exynos_crtc->pending_flip_queue,
>   !atomic_read(_crtc->pending_flip),
> - HZ/20))
> + HZ/20)) {
>   atomic_set(_crtc->pending_flip, 0);
> - drm_vblank_off(crtc->dev, exynos_crtc->pipe);
> + drm_crtc_vblank_put(crtc);
> + }
>   }
>  
>   if (manager->ops->dpms)
> 

[Bug 84601] vaapi state tracker does not work on radeonsi (Hawaii)

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

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

--- Comment #3 from darkbasic  ---
Recomping somehow helped, vaapi works now but I still have to symlink
gallium_drv_video.so to radeonsi_drv_video.so.

-- 
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/20141002/3afc01a0/attachment.html>

[Bug 83510] Graphical glitches in Unreal Engine 4

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

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

Christoph Haag  changed:

   What|Removed |Added

 CC||haagch at frickel.club

--- Comment #6 from Christoph Haag  ---
HD 7970M pitcairn here.

On an early unreal tournament pre-alpha build I had these artifacts very
extremely:
https://www.youtube.com/watch?v=mjbANgbIR6o

In a new build they are reduced, but it still happens:
https://www.youtube.com/watch?v=J4yT2cUXMcw

Here is another Video from another user with a HD 7790M:
https://www.youtube.com/watch?v=0-zlT93DdyU



When you are talking about motion blur on cameras, are you talking about the
glitch you can see in this video? https://www.youtube.com/watch?v=lkDLlCEBKPA
This happened a while ago and it does not happen anymore. I think at least for
me this is fixed.



But I think my Realistic Rendering demo is still too dark too.

-- 
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/20141002/8a46592a/attachment.html>

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave, final regression fix for 3.17.

BR,
Jani.


The following changes since commit fe82dcec644244676d55a1384c958d5f67979adb:

  Linux 3.17-rc7 (2014-09-28 14:29:07 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-10-02

for you to fetch changes up to 91e56499304f3d612053a9cf17f350868182c7d8:

  drm/i915: Flush the PTEs after updating them before suspend (2014-09-29 
16:41:17 +0300)


Chris Wilson (1):
  drm/i915: Flush the PTEs after updating them before suspend

 drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/core: use helper to check driver features

[David Herrmann]

Hi

On Tue, Sep 30, 2014 at 4:49 PM, Andrzej Hajda  wrote:
> The patch replaces direct access to driver_features field
> by calls to helper function.
>
> Signed-off-by: Andrzej Hajda 

Looks good:

Reviewed-by: David Herrmann 

CC'ing Daniel, he'll put it in his drm-core-stuff branch.

Thanks
David

> ---
>  drivers/gpu/drm/drm_drv.c  | 4 ++--
>  drivers/gpu/drm/drm_fops.c | 8 
>  drivers/gpu/drm/drm_gem.c  | 6 +++---
>  3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 6a11902..2b30430 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -598,7 +598,7 @@ struct drm_device *drm_dev_alloc(struct drm_driver 
> *driver,
> goto err_ht;
> }
>
> -   if (driver->driver_features & DRIVER_GEM) {
> +   if (drm_core_check_feature(dev, DRIVER_GEM)) {
> ret = drm_gem_init(dev);
> if (ret) {
> DRM_ERROR("Cannot initialize graphics execution 
> manager (GEM)\n");
> @@ -628,7 +628,7 @@ static void drm_dev_release(struct kref *ref)
>  {
> struct drm_device *dev = container_of(ref, struct drm_device, ref);
>
> -   if (dev->driver->driver_features & DRIVER_GEM)
> +   if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_destroy(dev);
>
> drm_legacy_ctxbitmap_cleanup(dev);
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 3e66946..ed7bc68 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -171,7 +171,7 @@ static int drm_open_helper(struct file *filp, struct 
> drm_minor *minor)
> init_waitqueue_head(>event_wait);
> priv->event_space = 4096; /* set aside 4k for event buffer */
>
> -   if (dev->driver->driver_features & DRIVER_GEM)
> +   if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_open(dev, priv);
>
> if (drm_core_check_feature(dev, DRIVER_PRIME))
> @@ -256,7 +256,7 @@ out_close:
>  out_prime_destroy:
> if (drm_core_check_feature(dev, DRIVER_PRIME))
> drm_prime_destroy_file_private(>prime);
> -   if (dev->driver->driver_features & DRIVER_GEM)
> +   if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_release(dev, priv);
> put_pid(priv->pid);
> kfree(priv);
> @@ -408,10 +408,10 @@ int drm_release(struct inode *inode, struct file *filp)
>
> drm_events_release(file_priv);
>
> -   if (dev->driver->driver_features & DRIVER_MODESET)
> +   if (drm_core_check_feature(dev, DRIVER_MODESET))
> drm_fb_release(file_priv);
>
> -   if (dev->driver->driver_features & DRIVER_GEM)
> +   if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_release(dev, file_priv);
>
> drm_legacy_ctxbitmap_flush(dev, file_priv);
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index eb5dd67..b2c7bab 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -580,7 +580,7 @@ drm_gem_close_ioctl(struct drm_device *dev, void *data,
> struct drm_gem_close *args = data;
> int ret;
>
> -   if (!(dev->driver->driver_features & DRIVER_GEM))
> +   if (!drm_core_check_feature(dev, DRIVER_GEM))
> return -ENODEV;
>
> ret = drm_gem_handle_delete(file_priv, args->handle);
> @@ -607,7 +607,7 @@ drm_gem_flink_ioctl(struct drm_device *dev, void *data,
> struct drm_gem_object *obj;
> int ret;
>
> -   if (!(dev->driver->driver_features & DRIVER_GEM))
> +   if (!drm_core_check_feature(dev, DRIVER_GEM))
> return -ENODEV;
>
> obj = drm_gem_object_lookup(dev, file_priv, args->handle);
> @@ -660,7 +660,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
> int ret;
> u32 handle;
>
> -   if (!(dev->driver->driver_features & DRIVER_GEM))
> +   if (!drm_core_check_feature(dev, DRIVER_GEM))
> return -ENODEV;
>
> mutex_lock(>object_name_lock);
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 84601] vaapi state tracker does not work on radeonsi (Hawaii)

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

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

--- Comment #2 from darkbasic  ---
I already tried to symlink it without success.

-- 
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/20141002/75a5bfdf/attachment.html>

[PATCH 02/22] drm/radeon/dpm: add new callbacks to get the current sclk/mclk

[Christian König]

Am 02.10.2014 um 15:06 schrieb Alex Deucher:
> On Thu, Oct 2, 2014 at 8:26 AM, Christian K?nig  
> wrote:
>> Might be a good idea to make that a bit more generic, e.g. add a
>> get_current_clk callback and and a type (sclk, mclk, vclk, dclk, etc..)
>> enum. But I can live with this approach as well.
>>
> Yeah, I thought about that, but I'm not sure if there is a good way to
> query that for certain clocks when dynamic clocking is enabled.  E.g.,
> UVD on newer asics.

That's why I always favored using the PLL test registers. It can 
actually measure the clocks quite precisely if the reference clock 
(usually the PCI clock) is stable enough. And as far as I know can 
access any clock signal in the system, even the memory clock is 
measurable for each memory interface separately.

Christian.

>
> Alex
>
>> Christian.
>>
>> Am 01.10.2014 um 17:38 schrieb Alex Deucher:
>>
>>> Needed to to expose the current clocks via the INFO ioctl.
>>>
>>> Signed-off-by: Alex Deucher 
>>> ---
>>>drivers/gpu/drm/radeon/radeon.h | 4 
>>>1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>>> b/drivers/gpu/drm/radeon/radeon.h
>>> index 510fe96..9e3dc82 100644
>>> --- a/drivers/gpu/drm/radeon/radeon.h
>>> +++ b/drivers/gpu/drm/radeon/radeon.h
>>> @@ -1935,6 +1935,8 @@ struct radeon_asic {
>>>  bool (*vblank_too_short)(struct radeon_device *rdev);
>>>  void (*powergate_uvd)(struct radeon_device *rdev, bool
>>> gate);
>>>  void (*enable_bapm)(struct radeon_device *rdev, bool
>>> enable);
>>> +   u32 (*get_current_sclk)(struct radeon_device *rdev);
>>> +   u32 (*get_current_mclk)(struct radeon_device *rdev);
>>>  } dpm;
>>>  /* pageflipping */
>>>  struct {
>>> @@ -2893,6 +2895,8 @@ static inline void radeon_ring_write(struct
>>> radeon_ring *ring, uint32_t v)
>>>#define radeon_dpm_vblank_too_short(rdev)
>>> rdev->asic->dpm.vblank_too_short((rdev))
>>>#define radeon_dpm_powergate_uvd(rdev, g)
>>> rdev->asic->dpm.powergate_uvd((rdev), (g))
>>>#define radeon_dpm_enable_bapm(rdev, e)
>>> rdev->asic->dpm.enable_bapm((rdev), (e))
>>> +#define radeon_dpm_get_current_sclk(rdev)
>>> rdev->asic->dpm.get_current_sclk((rdev))
>>> +#define radeon_dpm_get_current_mclk(rdev)
>>> rdev->asic->dpm.get_current_mclk((rdev))
>>>  /* Common functions */
>>>/* AGP */
>>

[Bug 84601] vaapi state tracker does not work on radeonsi (Hawaii)

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

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

--- Comment #1 from darkbasic  ---
There is no /usr/lib64/va/drivers/radeonsi_drv_video.so, just
gallium_drv_video.so

-- 
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/20141002/10a4ba5a/attachment.html>

[Bug 84601] New: vaapi state tracker does not work on radeonsi (Hawaii)

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

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

Bug ID: 84601
   Summary: vaapi state tracker does not work on radeonsi (Hawaii)
   Product: DRI
   Version: XOrg CVS
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: darkbasic at linuxsystems.it

~ $ mpv -vo=opengl-hq -hwdec=vaapi test.mkv 
Playing: test.mkv
Can not open external file test.txt.
[stream] Video (+) --vid=1 (h264)
[stream] Audio (+) --aid=1 (*) (ac3)
libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
libva info: va_openDriver() returns -1
[vaapi] vaInitialize(): unknown libva error
[vo/opengl-hq] Couldn't load hwdec driver 'vaapi'
VO does not support requested hardware decoder.
Using software decoding.
AO: [pulse] 48000Hz stereo 2ch float
VO: [opengl-hq] 1280x720 => 1280x720 yuv420p
AV: 00:00:10 / 00:41:37 (0%) A-V: 0.000





~ $ vlc test.mkv 
VLC media player 2.1.5 Rincewind (revision 2.1.4-49-gdab6cb5)
[0xd561f8] main libvlc: Esecuzione di vlc con l'interfaccia predefinita. Usa
'cvlc' per utilizzare vlc senza interfaccia.
[0xe37918] qt4 interface error: Unable to load extensions module
[0x7f6bc109b9e8] main demux error: option sub-original-fps does not exist
[0x7f6bb0001208] main input error: no suitable demux module for
`file/subtitle:///home/niko//test.txt'
No accelerated IMDCT transform found
libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
libva info: va_openDriver() returns -1
[0x7f6b9c000db8] vaapi generic error: Failed to initialize the VAAPI device
libva info: VA-API version 0.35.1
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so
libva info: va_openDriver() returns -1
[0x7f6b9c000db8] vaapi generic error: Failed to initialize the VAAPI device
[0x7f6b8c001248] main vout display error: Failed to resize display

-- 
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/20141002/12f9985f/attachment.html>

[PATCH 00/22] new radeon info queries

[Christian König]

Am 02.10.2014 um 06:50 schrieb Alex Deucher:
> On Wed, Oct 1, 2014 at 12:30 PM, Alexandre Demers
>  wrote:
>> May I suggest something more to add if available? It would be great to
>> have the core and memory voltages. As an example of a specific
>> application where it would have been usefull: it would have been
>> easier to debug the problem with Cayman when vddci was not correctly
>> set (it would have been higher or lower than expected or the value
>> would have been nonsense).
> It wouldn't have helped for that problem since there's no way to query
> the actual vddc or vddci or even the clocks.  All you can query is
> which performance level is active, the driver has to determine the
> clocks and voltages based on that.  It's basically the same info that
> is already exposed via debugfs.

I hoped we could expose the PLL test registers as well, this way 
somebody could actually measure at least the clocks instead of just 
calculating them from the PM profile in use.

Christian.

>
> Alex
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/22] drm/radeon/dpm: add new callbacks to get the current sclk/mclk

[Christian König]

Might be a good idea to make that a bit more generic, e.g. add a 
get_current_clk callback and and a type (sclk, mclk, vclk, dclk, etc..) 
enum. But I can live with this approach as well.

Christian.

Am 01.10.2014 um 17:38 schrieb Alex Deucher:
> Needed to to expose the current clocks via the INFO ioctl.
>
> Signed-off-by: Alex Deucher 
> ---
>   drivers/gpu/drm/radeon/radeon.h | 4 
>   1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 510fe96..9e3dc82 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1935,6 +1935,8 @@ struct radeon_asic {
>   bool (*vblank_too_short)(struct radeon_device *rdev);
>   void (*powergate_uvd)(struct radeon_device *rdev, bool gate);
>   void (*enable_bapm)(struct radeon_device *rdev, bool enable);
> + u32 (*get_current_sclk)(struct radeon_device *rdev);
> + u32 (*get_current_mclk)(struct radeon_device *rdev);
>   } dpm;
>   /* pageflipping */
>   struct {
> @@ -2893,6 +2895,8 @@ static inline void radeon_ring_write(struct radeon_ring 
> *ring, uint32_t v)
>   #define radeon_dpm_vblank_too_short(rdev) 
> rdev->asic->dpm.vblank_too_short((rdev))
>   #define radeon_dpm_powergate_uvd(rdev, g) 
> rdev->asic->dpm.powergate_uvd((rdev), (g))
>   #define radeon_dpm_enable_bapm(rdev, e) rdev->asic->dpm.enable_bapm((rdev), 
> (e))
> +#define radeon_dpm_get_current_sclk(rdev) 
> rdev->asic->dpm.get_current_sclk((rdev))
> +#define radeon_dpm_get_current_mclk(rdev) 
> rdev->asic->dpm.get_current_mclk((rdev))
>   
>   /* Common functions */
>   /* AGP */

[PATCH] drm/exynos: fix vblank handling during dpms off

[Andrzej Hajda]

Hi,

+CC possible victims

On 10/02/2014 12:52 PM, Inki Dae wrote:
> On 2014? 10? 02? 17:58, Joonyoung Shim wrote:
>> Hi Andrzej,
>>
>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
>>> The patch disables vblanks during dpms off only if pagefilp has
>>> not been finished. It also replaces drm_vblank_off with drm_crtc_vblank_put.
>>> It fixes issue with page_flip ioctl not being able to acquire vblank 
>>> counter.
>> This problem isn't related with pageflip, it just causes from
>> 7ffd7a68511c710b84db3548a1997fd2625f580a commit (drm: Always reject
>> drm_vblank_get() after drm_vblank_off()).
>>
>> We need to use drm_vblank_on() as a counterpart to drm_vblank_off()
>> after the commit .

This patch should break also other drivers, it seems at least following
drms could be affected:
armada, sti, tegra.

I guess after disabling and re-enabling crtc vblanks should stop
working, unless there are other bugs.

Regards
Andrzej

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

--- Comment #9 from Alex Deucher  ---
Well, about lids in general.

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

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

--- Comment #8 from Alex Deucher  ---
Comment 5 specifically.

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

[Bug 83651] radeon: kernel returns invalid information about video connectors' status

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

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

--- Comment #7 from Garri  ---
(In reply to Alex Deucher from comment #6)
> The lid issue is more semantic.  The display is still connected even when
> the lid is closed so it should still report as connected.  It's up to the
> desktop environment to decide what to do when they get a lid event.

Alex, is your reply addressed to the comment 5 or to the bug report generally?

Thanks.

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

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

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

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

--- Comment #8 from Christian K?nig  ---
(In reply to Michel D?nzer from comment #7)
> So, it looks like the value for the R_028A3C_VGT_GROUP_VECT_1_FMT_CNTL
> register and the following PKT3_SET_CONTEXT_REG header were scribbled over
> with the value 0x000b. Looks like memory corruption to me.

Yeah, agree that strongly looks like a memory corruption. Which would also
explain all the crashes.

-- 
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/20141002/6b4533f1/attachment.html>

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl

[Tomasz Figa]

On 02.10.2014 12:25, Inki Dae wrote:
> On 2014? 10? 02? 08:47, Joonyoung Shim wrote:
>> Hi Tomasz,
>>
>> On 10/02/2014 12:13 AM, Tomasz Figa wrote:
>>> Hi Inki,
>>>
>>> On 17.09.2014 15:48, Inki Dae wrote:
 This interface and relevant codes aren't used anymore.

>>>
>>> Hmm, I might be missing something, but after removing this IOCTL, how do
>>> we obtain an offset to pass to mmap()?
>>
>> There is DRM_IOCTL_MODE_MAP_DUMB, it can get mmap offset before mmap and
>> the offset is passed via mmap.
> 
> Exactly. That will lead us to more generic world.

OK. Thanks Joonyoung, Inki, for quick response. I was confused by name
of this IOCTL. I'll modify my code to use it.

Best regards,
Tomasz

[PATCH] drm/nouveau: gk20a: Fix type of dividend in do_div()

[Thierry Reding]

From: Thierry Reding 

The semantics of do_div() are (see include/asm-generic/div64.h):

uint32_t do_div(uint64_t *n, uint32_t base)

Using a different type will therefore cause the following warning (as
seen on xtensa/allmodconfig):

  CC [M]  drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.o
In file included from arch/xtensa/include/generated/asm/div64.h:1:0,
 from include/linux/kernel.h:124,
 from include/linux/list.h:8,
 from include/linux/preempt.h:10,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from include/linux/slab.h:14,
 from drivers/gpu/drm/nouveau/core/os.h:5,
 from 
drivers/gpu/drm/nouveau/core/include/core/object.h:4,
 from 
drivers/gpu/drm/nouveau/core/include/core/device.h:4,
 from 
drivers/gpu/drm/nouveau/core/include/subdev/clock.h:4,
 from 
drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:90:
drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c: In function 
'gk20a_pllg_calc_rate':
include/asm-generic/div64.h:43:28: warning: comparison of distinct 
pointer types lacks a cast
  (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:146:2: note: in 
expansion of macro 'do_div'
  do_div(rate, divider);
  ^
drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:146:2: warning: right 
shift count >= width of type
In file included from arch/xtensa/include/generated/asm/div64.h:1:0,
 from include/linux/kernel.h:124,
 from include/linux/list.h:8,
 from include/linux/preempt.h:10,
 from include/linux/spinlock.h:50,
 from include/linux/mmzone.h:7,
 from include/linux/gfp.h:5,
 from include/linux/slab.h:14,
 from drivers/gpu/drm/nouveau/core/os.h:5,
 from 
drivers/gpu/drm/nouveau/core/include/core/object.h:4,
 from 
drivers/gpu/drm/nouveau/core/include/core/device.h:4,
 from 
drivers/gpu/drm/nouveau/core/include/subdev/clock.h:4,
 from 
drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:90:
include/asm-generic/div64.h:48:11: warning: passing argument 1 of 
'__div64_32' from incompatible pointer type
   __rem = __div64_32(&(n), __base); \
   ^
drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c:146:2: note: in 
expansion of macro 'do_div'
  do_div(rate, divider);
  ^
include/asm-generic/div64.h:35:17: note: expected 'uint64_t *' but 
argument is of type 'u32 *'
 extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c 
b/drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c
index 425a8d5e9129..c571437afbd2 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/clock/gk20a.c
@@ -138,7 +138,7 @@ gk20a_pllg_read_mnp(struct gk20a_clock_priv *priv)
 static u32
 gk20a_pllg_calc_rate(struct gk20a_clock_priv *priv)
 {
-   u32 rate;
+   u64 rate;
u32 divider;

rate = priv->parent_rate * priv->n;
-- 
2.1.0

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #74 from Christoph Haag  ---
Well.

I have said that I used drm-next-3.18 and had these hangs.
When I applied
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066746.html it did
not help.

Now I am using 3.17-rc7 with that mesa patch and I do not see these hangs
anymore. Or maybe they are these very short stutters.

Sorry if drm-next-3.18 behavior is not relevant here.

As for the num bytes moved: Does the HUD graph only accumulate everything that
happened in the hang? If so, then the hundreds of megabytes still seem more
than normal and the used graphs definitely show change before and after the
hangs. Whatever you make of that...


CONFIG_CMA is not enabled on either kernel.

Indeed, there's less moving of data with the rc kernel I think.
For comparison: https://www.youtube.com/watch?v=mFaqHGle9Hg

-- 
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/20141002/4055ea20/attachment.html>

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #136 from agapito  ---
With the kernel 3.17 rc7 the crashes are a lot more frequent than 3.16.4
kernel.

-- 
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/20141002/8934e983/attachment-0001.html>

randconfig build error with next-20141001, in drivers/gpu/drm/i915

[Jani Nikula]

On Wed, 01 Oct 2014, Randy Dunlap  wrote:
> On 10/01/14 10:57, Jani Nikula wrote:
>> On Wed, 01 Oct 2014, Jim Davis  wrote:
>>> Building with the attached random configuration file,
>>>
>>> warning: (VIDEO_TIMBERDALE) selects TIMB_DMA which has unmet direct
>>> dependencies (DMADEVICES && MFD_TIMBERDALE)
>>> warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG
>>> which has unmet direct dependencies (USB_SUPPORT && USB && PM_RUNTIME)
>>>
>>> drivers/built-in.o: In function `intel_panel_setup_backlight':
>>> (.text+0x11855d): undefined reference to `backlight_device_register'
>>> drivers/built-in.o: In function `intel_panel_destroy_backlight':
>>> (.text+0x118624): undefined reference to `backlight_device_unregister'
>>> make: *** [vmlinux] Error 1
>> 
>> It's the combination:
>> 
>>> CONFIG_DRM_I915=y
>>> CONFIG_BACKLIGHT_CLASS_DEVICE=m
>> 
>> Not sure what the Kconfig magic spell needs to be when we don't want to
>> depend on CONFIG_BACKLIGHT_CLASS_DEVICE but we'll use it if it's enabled
>> (y or m).
>
> Something like:
>
>   depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
>
> is what we usually use.

Oh boy this gets ugly. Trying

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4e39ab34eb1c..daa453c62aa6 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -3,6 +3,7 @@ config DRM_I915
depends on DRM
depends on X86 && PCI
depends on (AGP || AGP=n)
+   depends on (BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n)
select INTEL_GTT
select AGP_INTEL if AGP
select INTERVAL_TREE

leads to

scripts/kconfig/conf --olddefconfig Kconfig
drivers/gpu/drm/i915/Kconfig:1:error: recursive dependency detected!
drivers/gpu/drm/i915/Kconfig:1: symbol DRM_I915 depends on 
BACKLIGHT_CLASS_DEVICE
drivers/video/backlight/Kconfig:156:symbol BACKLIGHT_CLASS_DEVICE is 
selected by DRM_I915

because we depend on ACPI_VIDEO when ACPI is enabled, originally done in

commit ecb4aed78dcf09e48c8c34c8c2fa7f5c69344be6
Author: Len Brown 
Date:   Fri Apr 24 11:33:47 2009 -0400

ACPI, i915: build fix

Now, trying to fix that with what seems to me like the obvious
dependency, conveying what we really want

diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4e39ab34eb1c..f5a1ee37603e 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -3,6 +3,7 @@ config DRM_I915
depends on DRM
depends on X86 && PCI
depends on (AGP || AGP=n)
+   depends on ((ACPI && ACPI_VIDEO) || ACPI=n)
select INTEL_GTT
select AGP_INTEL if AGP
select INTERVAL_TREE
@@ -11,13 +12,6 @@ config DRM_I915
select SHMEM
select TMPFS
select DRM_KMS_HELPER
-   # i915 depends on ACPI_VIDEO when ACPI is enabled
-   # but for select to work, need to select ACPI_VIDEO's dependencies, ick
-   select BACKLIGHT_LCD_SUPPORT if ACPI
-   select BACKLIGHT_CLASS_DEVICE if ACPI
-   select INPUT if ACPI
-   select ACPI_VIDEO if ACPI
-   select ACPI_BUTTON if ACPI
help
  Choose this option if you have a system that has "Intel Graphics
  Media Accelerator" or "HD Graphics" integrated graphics,

leads to more fun

scripts/kconfig/conf --olddefconfig Kconfig
drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
drivers/video/fbdev/Kconfig:5:  symbol FB is selected by DRM_KMS_FB_HELPER
drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER is selected by 
DRM_I915_FBDEV
drivers/gpu/drm/i915/Kconfig:40:symbol DRM_I915_FBDEV depends on 
DRM_I915
drivers/gpu/drm/i915/Kconfig:1: symbol DRM_I915 depends on ACPI_VIDEO
drivers/acpi/Kconfig:130:   symbol ACPI_VIDEO is selected by 
BACKLIGHT_CLASS_DEVICE
drivers/video/backlight/Kconfig:156:symbol BACKLIGHT_CLASS_DEVICE is 
selected by FB_BACKLIGHT
drivers/video/fbdev/Kconfig:188:symbol FB_BACKLIGHT is selected by 
PMAC_BACKLIGHT
drivers/macintosh/Kconfig:135:  symbol PMAC_BACKLIGHT depends on FB

and the rabbit hole gets deeper than I thought. I guess it always does.

At this point the question is whether "depends on ((ACPI && ACPI_VIDEO)
|| ACPI=n)" is worth pursuing and makes more sense than the "select foo
if ACPI" lines, or do we need to build hacks upon hacks to get this
fixed.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH 2/2] drm/radeon/kv: add uvd/vce info to dpm debugfs output

[Alex Deucher]

Track whether UVD or VCE are enabled in debugfs.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/kv_dpm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/radeon/kv_dpm.c b/drivers/gpu/drm/radeon/kv_dpm.c
index bffacd9..e50b636 100644
--- a/drivers/gpu/drm/radeon/kv_dpm.c
+++ b/drivers/gpu/drm/radeon/kv_dpm.c
@@ -2773,6 +2773,8 @@ void 
kv_dpm_debugfs_print_current_performance_level(struct radeon_device *rdev,
tmp = (RREG32_SMC(SMU_VOLTAGE_STATUS) & 
SMU_VOLTAGE_CURRENT_LEVEL_MASK) >>
SMU_VOLTAGE_CURRENT_LEVEL_SHIFT;
vddc = kv_convert_8bit_index_to_voltage(rdev, (u16)tmp);
+   seq_printf(m, "uvd%sabled\n", pi->uvd_power_gated ? "dis" : 
"en");
+   seq_printf(m, "vce%sabled\n", pi->vce_power_gated ? "dis" : 
"en");
seq_printf(m, "power level %dsclk: %u vddc: %u\n",
   current_index, sclk, vddc);
}
-- 
1.8.3.1

[PATCH 1/2] drm/radeon/ci: add uvd/vce info to dpm debugfs output

[Alex Deucher]

Track whether UVD or VCE are enabled in debugfs.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index cdefdf3..5d4cc5c 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -5267,9 +5267,13 @@ int ci_dpm_init(struct radeon_device *rdev)
 void ci_dpm_debugfs_print_current_performance_level(struct radeon_device *rdev,
struct seq_file *m)
 {
+   struct ci_power_info *pi = ci_get_pi(rdev);
+   struct radeon_ps *rps = >current_rps;
u32 sclk = ci_get_average_sclk_freq(rdev);
u32 mclk = ci_get_average_mclk_freq(rdev);

+   seq_printf(m, "uvd%sabled\n", pi->uvd_enabled ? "en" : "dis");
+   seq_printf(m, "vce%sabled\n", rps->vce_active ? "en" : "dis");
seq_printf(m, "power level avgsclk: %u mclk: %u\n",
   sclk, mclk);
 }
-- 
1.8.3.1

randconfig build error with next-20141001, in drivers/gpu/drm/i915

[Randy Dunlap]

On 10/02/14 00:46, Jani Nikula wrote:
> On Wed, 01 Oct 2014, Randy Dunlap  wrote:
>> On 10/01/14 10:57, Jani Nikula wrote:
>>> On Wed, 01 Oct 2014, Jim Davis  wrote:
 Building with the attached random configuration file,

 warning: (VIDEO_TIMBERDALE) selects TIMB_DMA which has unmet direct
 dependencies (DMADEVICES && MFD_TIMBERDALE)
 warning: (USB_OTG_FSM && FSL_USB2_OTG && USB_MV_OTG) selects USB_OTG
 which has unmet direct dependencies (USB_SUPPORT && USB && PM_RUNTIME)

 drivers/built-in.o: In function `intel_panel_setup_backlight':
 (.text+0x11855d): undefined reference to `backlight_device_register'
 drivers/built-in.o: In function `intel_panel_destroy_backlight':
 (.text+0x118624): undefined reference to `backlight_device_unregister'
 make: *** [vmlinux] Error 1
>>>
>>> It's the combination:
>>>
 CONFIG_DRM_I915=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=m
>>>
>>> Not sure what the Kconfig magic spell needs to be when we don't want to
>>> depend on CONFIG_BACKLIGHT_CLASS_DEVICE but we'll use it if it's enabled
>>> (y or m).
>>
>> Something like:
>>
>>  depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
>>
>> is what we usually use.
> 
> Oh boy this gets ugly. Trying
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4e39ab34eb1c..daa453c62aa6 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -3,6 +3,7 @@ config DRM_I915
>   depends on DRM
>   depends on X86 && PCI
>   depends on (AGP || AGP=n)
> + depends on (BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n)
>   select INTEL_GTT
>   select AGP_INTEL if AGP
>   select INTERVAL_TREE
> 
> leads to
> 
> scripts/kconfig/conf --olddefconfig Kconfig
> drivers/gpu/drm/i915/Kconfig:1:error: recursive dependency detected!
> drivers/gpu/drm/i915/Kconfig:1:   symbol DRM_I915 depends on 
> BACKLIGHT_CLASS_DEVICE
> drivers/video/backlight/Kconfig:156:  symbol BACKLIGHT_CLASS_DEVICE is 
> selected by DRM_I915
> 
> because we depend on ACPI_VIDEO when ACPI is enabled, originally done in
> 
> commit ecb4aed78dcf09e48c8c34c8c2fa7f5c69344be6
> Author: Len Brown 
> Date:   Fri Apr 24 11:33:47 2009 -0400
> 
> ACPI, i915: build fix
> 
> Now, trying to fix that with what seems to me like the obvious
> dependency, conveying what we really want
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4e39ab34eb1c..f5a1ee37603e 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -3,6 +3,7 @@ config DRM_I915
>   depends on DRM
>   depends on X86 && PCI
>   depends on (AGP || AGP=n)
> + depends on ((ACPI && ACPI_VIDEO) || ACPI=n)
>   select INTEL_GTT
>   select AGP_INTEL if AGP
>   select INTERVAL_TREE
> @@ -11,13 +12,6 @@ config DRM_I915
>   select SHMEM
>   select TMPFS
>   select DRM_KMS_HELPER
> - # i915 depends on ACPI_VIDEO when ACPI is enabled
> - # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> - select BACKLIGHT_LCD_SUPPORT if ACPI
> - select BACKLIGHT_CLASS_DEVICE if ACPI
> - select INPUT if ACPI
> - select ACPI_VIDEO if ACPI
> - select ACPI_BUTTON if ACPI
>   help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> 
> leads to more fun
> 
> scripts/kconfig/conf --olddefconfig Kconfig
> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected!
> drivers/video/fbdev/Kconfig:5:symbol FB is selected by 
> DRM_KMS_FB_HELPER
> drivers/gpu/drm/Kconfig:34:   symbol DRM_KMS_FB_HELPER is selected by 
> DRM_I915_FBDEV
> drivers/gpu/drm/i915/Kconfig:40:  symbol DRM_I915_FBDEV depends on 
> DRM_I915
> drivers/gpu/drm/i915/Kconfig:1:   symbol DRM_I915 depends on ACPI_VIDEO
> drivers/acpi/Kconfig:130: symbol ACPI_VIDEO is selected by 
> BACKLIGHT_CLASS_DEVICE
> drivers/video/backlight/Kconfig:156:  symbol BACKLIGHT_CLASS_DEVICE is 
> selected by FB_BACKLIGHT
> drivers/video/fbdev/Kconfig:188:  symbol FB_BACKLIGHT is selected by 
> PMAC_BACKLIGHT
> drivers/macintosh/Kconfig:135:symbol PMAC_BACKLIGHT depends on FB
> 
> and the rabbit hole gets deeper than I thought. I guess it always does.
> 
> At this point the question is whether "depends on ((ACPI && ACPI_VIDEO)
> || ACPI=n)" is worth pursuing and makes more sense than the "select foo
> if ACPI" lines, or do we need to build hacks upon hacks to get this
> fixed.

I certainly prefer the depends that you added to all of those selects.

I'm afraid that I can't help you much here other than to say that if you
can express the driver needs with depends instead of select, you should
come out ahead by removing some of the depth of the rabbit hole.


-- 
~Randy

[PATCH] drm/mgag200: Fix type of dividend in do_div()

[Thierry Reding]

From: Thierry Reding 

The semantics of do_div() are (see include/asm-generic/do_div.h):

uint32_t do_div(uint64_t *n, uint32_t base)

Using a different type will therefore cause the following warning (as
seen on xtensa/allmodconfig):

  CC [M]  drivers/gpu/drm/mgag200/mgag200_mode.o
In file included from arch/xtensa/include/generated/asm/div64.h:1:0,
 from include/linux/kernel.h:124,
 from include/linux/delay.h:10,
 from drivers/gpu/drm/mgag200/mgag200_mode.c:14:
drivers/gpu/drm/mgag200/mgag200_mode.c: In function 
'mga_vga_calculate_mode_bandwidth':
include/asm-generic/div64.h:43:28: warning: comparison of distinct 
pointer types lacks a cast
  (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/gpu/drm/mgag200/mgag200_mode.c:1471:2: note: in expansion of 
macro 'do_div'
  do_div(pixels_per_second, total_area);
  ^
include/asm-generic/div64.h:43:28: warning: comparison of distinct 
pointer types lacks a cast
  (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/gpu/drm/mgag200/mgag200_mode.c:1474:2: note: in expansion of 
macro 'do_div'
  do_div(bandwidth, divisor);
  ^

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 83485ab81ce8..4d519dc99db8 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1455,9 +1455,9 @@ static int mga_vga_get_modes(struct drm_connector 
*connector)
 static uint32_t mga_vga_calculate_mode_bandwidth(struct drm_display_mode *mode,
int bits_per_pixel)
 {
-   uint32_t total_area, divisor;
-   int64_t active_area, pixels_per_second, bandwidth;
uint64_t bytes_per_pixel = (bits_per_pixel + 7) / 8;
+   uint32_t total_area, divisor, active_area;
+   uint64_t pixels_per_second, bandwidth;

divisor = 1024;

-- 
2.1.0

[PATCH 02/22] drm/radeon/dpm: add new callbacks to get the current sclk/mclk

[Alex Deucher]

On Thu, Oct 2, 2014 at 8:26 AM, Christian K?nig  
wrote:
> Might be a good idea to make that a bit more generic, e.g. add a
> get_current_clk callback and and a type (sclk, mclk, vclk, dclk, etc..)
> enum. But I can live with this approach as well.
>

Yeah, I thought about that, but I'm not sure if there is a good way to
query that for certain clocks when dynamic clocking is enabled.  E.g.,
UVD on newer asics.

Alex

> Christian.
>
> Am 01.10.2014 um 17:38 schrieb Alex Deucher:
>
>> Needed to to expose the current clocks via the INFO ioctl.
>>
>> Signed-off-by: Alex Deucher 
>> ---
>>   drivers/gpu/drm/radeon/radeon.h | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>> b/drivers/gpu/drm/radeon/radeon.h
>> index 510fe96..9e3dc82 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -1935,6 +1935,8 @@ struct radeon_asic {
>> bool (*vblank_too_short)(struct radeon_device *rdev);
>> void (*powergate_uvd)(struct radeon_device *rdev, bool
>> gate);
>> void (*enable_bapm)(struct radeon_device *rdev, bool
>> enable);
>> +   u32 (*get_current_sclk)(struct radeon_device *rdev);
>> +   u32 (*get_current_mclk)(struct radeon_device *rdev);
>> } dpm;
>> /* pageflipping */
>> struct {
>> @@ -2893,6 +2895,8 @@ static inline void radeon_ring_write(struct
>> radeon_ring *ring, uint32_t v)
>>   #define radeon_dpm_vblank_too_short(rdev)
>> rdev->asic->dpm.vblank_too_short((rdev))
>>   #define radeon_dpm_powergate_uvd(rdev, g)
>> rdev->asic->dpm.powergate_uvd((rdev), (g))
>>   #define radeon_dpm_enable_bapm(rdev, e)
>> rdev->asic->dpm.enable_bapm((rdev), (e))
>> +#define radeon_dpm_get_current_sclk(rdev)
>> rdev->asic->dpm.get_current_sclk((rdev))
>> +#define radeon_dpm_get_current_mclk(rdev)
>> rdev->asic->dpm.get_current_mclk((rdev))
>> /* Common functions */
>>   /* AGP */
>
>

[PATCH 1/2] drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET ioctl

[Joonyoung Shim]

Hi Tomasz,

On 10/02/2014 12:13 AM, Tomasz Figa wrote:
> Hi Inki,
> 
> On 17.09.2014 15:48, Inki Dae wrote:
>> This interface and relevant codes aren't used anymore.
>>
> 
> Hmm, I might be missing something, but after removing this IOCTL, how do
> we obtain an offset to pass to mmap()?

There is DRM_IOCTL_MODE_MAP_DUMB, it can get mmap offset before mmap and
the offset is passed via mmap.

Thanks.

[Bug 74294] Awesomenauts can't launch with R600_LLVM=1

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

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

Alexandre Demers  changed:

   What|Removed |Added

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

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

[Bug 74294] Awesomenauts can't launch with R600_LLVM=1

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

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

--- Comment #5 from Alexandre Demers  ---
(In reply to Michel D?nzer from comment #4)
> radeonsi doesn't work without LLVM, so R600_LLVM=1 doesn't have any effect
> with it. OTOH I'd expect it to be affected by any issues like this affecting
> r600g with R600_LLVM=1.

Then I'm closing it. If someone hits it, he will reopen it.

-- 
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/20141002/6c8268e9/attachment.html>

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #73 from Michel D?nzer  ---
(In reply to Andy Furniss from comment #67)
> In summary AIUI the fact there is a pause causes a spike because the count
> is from the last frame rendered - which is way longer than normal due to the
> pause.

Still, it means that *some* BOs were moved during the pause, so it's not
impossible that the pause is somehow related to the BO moves.

BTW, make sure CONFIG_CMA isn't enabled in your kernels, in particular those
using Ubuntu.


(In reply to smoki from comment #68)
>  Offtopic...

Please don't clutter up bug reports with off-topic comments.

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

[Bug 82544] Unreal Engine 4 Elemental fails to start up on Cape Verde with LLVM assertion failure

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

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

Michel D?nzer  changed:

   What|Removed |Added

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

--- Comment #1 from Michel D?nzer  ---
Fixed with current LLVM SVN.

-- 
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/20141002/73447c90/attachment.html>

[Bug 82050] R9270X pyrit benchmark perf regressions with latest kernel/llvm

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

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

--- Comment #72 from Michel D?nzer  ---
(In reply to comment #62)
> I do have 2 gig, but looking at the screenshot of elemantal to be attached I
> see that used and requested differ.

That's probably because of VRAM fragmentation. (BTW, I find it easier to keep
track of this with requested-VRAM+VRAM-usage,requested-GTT+GTT-usage instead of
requested-VRAM+requested-GTT,VRAM-usage+GTT-usage)


> This shot doesn't really show how long the pauses are - they are really bad,
> it takes about 2 minutes to render the first few frames with pauses of many
> seconds after that.
> 
> It's so bad it's hard to tell whether the revert helps - probably not, I
> guess it's something different. Have you tried Elemental?

Yes, but even on Kaveri with only 1G of VRAM, it doesn't take two minutes for
it to get going, and I don't notice such long pauses either.

So I think it's better if we track the UE4 issues in a separate report, and it
would be great if you guys could bisect the kernel or Mesa for that.


(In reply to comment #65)
> Keep in mind that revert broke 32bit complitely, lot of corruption :)

I haven't been able to reproduce that. If you still can, please file a bug for
it, as there's nothing preventing the kernel from using GTT instead of VRAM
when the latter is full.


> I am not trying other demos , but seems like newer kernels requests more
> VRAM from the apps :)

The Mesa commit in question makes the r600g and radeonsi drivers try to use
VRAM for more things, but only with newer kernels, because older kernels didn't
guarantee reliability when using VRAM for those things.

-- 
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/20141002/71ddfed3/attachment-0001.html>

[Bug 74294] Awesomenauts can't launch with R600_LLVM=1

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

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

--- Comment #4 from Michel D?nzer  ---
radeonsi doesn't work without LLVM, so R600_LLVM=1 doesn't have any effect with
it. OTOH I'd expect it to be affected by any issues like this affecting r600g
with R600_LLVM=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/20141002/7266860e/attachment.html>

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

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

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

--- Comment #7 from Michel D?nzer  ---
> [25322.031213]0x000b

This value is written to the R_028A3C_VGT_GROUP_VECT_1_FMT_CNTL register.
However, the driver only ever writes 0 to that register, in si_init_config().

> [25322.031214]0x <---
> [25322.031215]0x0295
> [25322.031215]0x0080
> [25322.031216]0x0040
> [25322.031217]0x0002

The values after the arrow look like the following series of register writes to
R_028A54_VGT_GS_PER_ES and the two following registers.

So, it looks like the value for the R_028A3C_VGT_GROUP_VECT_1_FMT_CNTL register
and the following PKT3_SET_CONTEXT_REG header were scribbled over with the
value 0x000b. Looks like memory corruption to me.

Running firefox in valgrind or with something like the GCC / clang address
sanitizers might give a clue, but might be painful.

-- 
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/20141002/38d4d8eb/attachment.html>

[Bug 74294] Awesomenauts can't launch with R600_LLVM=1

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

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

--- Comment #3 from Alexandre Demers  ---
(In reply to Michel D?nzer from comment #2)
> Did you configure Mesa with --enable-r600-llvm-compiler? Without that,
> R600_LLVM=1 has no effect.

Yes it is. It's just that I was under the impression something had been changed
about how to use the LLVM backend.

I should have asked: does R600_LLVM=1 have any effect on the radeon_si driver?
I'm not using the same video card as before and the driver is not the r600g one
anymore.

-- 
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/20141002/98af1110/attachment.html>

[Bug 74294] Awesomenauts can't launch with R600_LLVM=1

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

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

--- Comment #2 from Michel D?nzer  ---
Did you configure Mesa with --enable-r600-llvm-compiler? Without that,
R600_LLVM=1 has no effect.

-- 
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/20141002/5e7bf8fc/attachment.html>

[PATCH 00/22] new radeon info queries

[Alex Deucher]

On Wed, Oct 1, 2014 at 12:30 PM, Alexandre Demers
 wrote:
> May I suggest something more to add if available? It would be great to
> have the core and memory voltages. As an example of a specific
> application where it would have been usefull: it would have been
> easier to debug the problem with Cayman when vddci was not correctly
> set (it would have been higher or lower than expected or the value
> would have been nonsense).

It wouldn't have helped for that problem since there's no way to query
the actual vddc or vddci or even the clocks.  All you can query is
which performance level is active, the driver has to determine the
clocks and voltages based on that.  It's basically the same info that
is already exposed via debugfs.

Alex

[Bug 74294] Awesomenauts can't launch with R600_LLVM=1

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

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

--- Comment #1 from Alexandre Demers  ---
tested with kernel 3.17-rc7, LLVM 3.5, mesa 10.4 (git) and it seems to work
fine now. Just to be sure, should I have added something else when launching
steam "R600_LLVM=1 steam"?

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

[Bug 85421] New: radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.

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

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

Bug ID: 85421
   Summary: radeon stalled, GPU lockup, reset and failed on
resume; crashed by firefox.
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16.3
  Hardware: x86-64
OS: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: htl10 at users.sourceforge.net
Regression: No

Created attachment 152191
  --> https://bugzilla.kernel.org/attachment.cgi?id=152191=edit
/var/log/messages from radeon :00:01.0: ring 0 stalled to reboot.

I was away from the computer when the radeon dri driver crashed; I left a fair
number of firefox windows on/tab, some of them may have videos (from BBC news
web site) and animated gifs from another web site on; but it crashed about 5-10
minutes after I was away and I was aware of it because the laptop blipped.

# lspci | grep VGA
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Mullins [Radeon R3 Graphics]

some excerpt from the attached logs are:

...
 [ 8770.250116] radeon :00:01.0: ring 0 stalled for more than 10012msec
 [ 8770.250128] radeon :00:01.0: GPU lockup (waiting for 0x00056034
last fence id 0x00056031 on ring 0)
 [ 8770.298635] radeon :00:01.0: Saved 14196 dwords of commands on ring 0.
 [ 8770.298663] radeon :00:01.0: GPU softreset: 0x000C
...
 [ 8770.313299] radeon :00:01.0: GPU reset succeeded, trying to resume
...
 [ 8770.339724] [drm] ring test on 0 succeeded in 3 usecs
 [ 8770.518568] [drm:cik_ring_test] *ERROR* radeon: ring 1 test failed
(scratch(0x3010C)=0xCAFEDEAD)
 [ 8770.752885] [drm:cik_sdma_ring_test] *ERROR* radeon: ring 3 test failed
(0xCAFEDEAD)
 [ 8770.752892] [drm:cik_resume] *ERROR* cik startup failed on resume
 [ 8780.753181] radeon :00:01.0: ring 0 stalled for more than 10001msec
 [ 8780.753193] radeon :00:01.0: GPU lockup (waiting for 0x000560f7
last fence id 0x00056031 on ring 0)
 [ 8780.753199] [drm:cik_ib_test] *ERROR* radeon: fence wait failed (-35).
 [ 8780.753209] [drm:radeon_ib_ring_tests] *ERROR* radeon: failed testing IB on
GFX ring (-35).
 [ 8780.753215] radeon :00:01.0: ib ring test failed (-35).
 [ 8780.762131] radeon :00:01.0: GPU softreset: 0x000C
...


The kernel is a largely fedora 3.16.3-200 one grabbed from the koji srpm but
with the additional patch from
https://bugzilla.kernel.org/show_bug.cgi?id=71051#c8

drv ati 7.4.0 , mesa 10.2.8, glamor from git 347ef4 .

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