[PATCH] Add missing lines to ci_set_thermal_temperature_range

[Oleg Chernovskiy]

Signed-off-by: Oleg Chernovskiy 
---
 drivers/gpu/drm/radeon/ci_dpm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 022561e..d416bb2 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -869,6 +869,9 @@ static int ci_set_thermal_temperature_range(struct 
radeon_device *rdev,
WREG32_SMC(CG_THERMAL_CTRL, tmp);
 #endif

+   rdev->pm.dpm.thermal.min_temp = low_temp;
+   rdev->pm.dpm.thermal.max_temp = high_temp;
+
return 0;
 }

-- 
2.0.4

Implementing the accelerated DRI/DRM driver for a pure 2D graphics card?

[Ilia Mirkin]

On Mon, Aug 11, 2014 at 9:42 AM, Tom Li  wrote:
> Hello everyone.
>
> I'm currently working on a DRM/KMS driver for the Silicon Motion SM712
> graphics card. Avoid the flicking between the VT-switching on my
> computer is what I want.
> This antiquated card doesn't support 3D and OpenGL stuff, but provide
> simple 2D acceleration by a drawing processor. Currently, the DDX
> driver xf86-video-siliconmotion directly accessing the hardware to
> write the registers for modesetting and 2D acceleration.
>
> But in the world of KMS/DRI, Xorg/DDX can't just control the cards and
> write the registers anymore. It is not a problem for modesetting
> because there's standard KMS way, but it prevent the DDX driver to
> access the 2D drawing processor. It is the problem, the card will
> become even more slower if it lost the only acceleration.
>
> Implement the complete DRI/DRM framework seems the right way to do it.
> But it seems the DRI/DRM are mainly designed for modern cards, 2D is
> just the subset of 3D / OpenGL, so it always got implemented
> automatically if we just implemented 3D. Many documents are talking
> about how to deal with the vertices / textures to implement 2D/3D, but
> I just have something like fillrect.
>
> So I just stuck at here. Is there a standard way to just let
> userspace/DDX to access the 2D drawing processor by the exported
> interface or DRI/DRM layer?

There's nothing specific to 3D in the DRM api's exposed by the kernel
drivers. They all just provide a method for submitting commands to the
card via ioctl's, manage buffers, etc. Each driver has its libdrm_foo
userspace API that hides the ioctl nastiness and provides a cleaner C
API. Many modern (and even older) hardware works by having a command
ring that the hardware processes, and userspace just provides lists of
those commands, as well as buffer management. Then the DDX and Mesa
and anything else that wants direct access uses the
libdrm_foo-provided APIs to submit commands to the card.

Hope this helps,

  -ilia

Implementing the accelerated DRI/DRM driver for a pure 2D graphics card?

[Tom Li]

Hello everyone.

I'm currently working on a DRM/KMS driver for the Silicon Motion SM712
graphics card. Avoid the flicking between the VT-switching on my
computer is what I want.
This antiquated card doesn't support 3D and OpenGL stuff, but provide
simple 2D acceleration by a drawing processor. Currently, the DDX
driver xf86-video-siliconmotion directly accessing the hardware to
write the registers for modesetting and 2D acceleration.

But in the world of KMS/DRI, Xorg/DDX can't just control the cards and
write the registers anymore. It is not a problem for modesetting
because there's standard KMS way, but it prevent the DDX driver to
access the 2D drawing processor. It is the problem, the card will
become even more slower if it lost the only acceleration.

Implement the complete DRI/DRM framework seems the right way to do it.
But it seems the DRI/DRM are mainly designed for modern cards, 2D is
just the subset of 3D / OpenGL, so it always got implemented
automatically if we just implemented 3D. Many documents are talking
about how to deal with the vertices / textures to implement 2D/3D, but
I just have something like fillrect.

So I just stuck at here. Is there a standard way to just let
userspace/DDX to access the 2D drawing processor by the exported
interface or DRI/DRM layer?

Thanks,

Tom Li

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

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

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

--- Comment #15 from Eugene  ---
There are only two r600_dri.so files:

locate r600_dri.so
/usr/lib/i386-linux-gnu/dri/r600_dri.so
/usr/lib/x86_64-linux-gnu/dri/r600_dri.so

And trying the one in i386-linux-gnu directory gives nothing. Only x86_64
version gives something
(https://crash-stats.mozilla.com/report/index/b964df8c-1a33-4302-ba89-686422140811):

addr2line 0x1ee641 -e /usr/lib/x86_64-linux-gnu/dri/r600_dri.so 
/build/buildd/mesa-10.3~git1408111930.904ed3+gallium/build/dri/src/mesa/../../../../src/gallium/auxiliary/util/u_inlines.h:151

addr2line 0x1c0669 -e /usr/lib/x86_64-linux-gnu/dri/r600_dri.so 
/build/buildd/mesa-10.3~git1408111930.904ed3+gallium/build/dri/src/mesa/../../../../src/mesa/state_tracker/st_cb_texture.c:157

addr2line 0x14da8d -e /usr/lib/x86_64-linux-gnu/dri/r600_dri.so 
/build/buildd/mesa-10.3~git1408111930.904ed3+gallium/build/dri/src/mesa/../../../../src/mesa/main/shared.c:298

addr2line 0x940bb -e /usr/lib/x86_64-linux-gnu/dri/r600_dri.so 
/build/buildd/mesa-10.3~git1408111930.904ed3+gallium/build/dri/src/mesa/../../../../src/mesa/main/context.c:1255

addr2line 0x1c47e0 -e /usr/lib/x86_64-linux-gnu/dri/r600_dri.so 
/build/buildd/mesa-10.3~git1408111930.904ed3+gallium/build/dri/src/mesa/../../../../src/mesa/state_tracker/st_context.c:333

addr2line 0x29adce -e /usr/lib/x86_64-linux-gnu/dri/r600_dri.so 
/build/buildd/mesa-10.3~git1408111930.904ed3+gallium/build/dri/src/gallium/state_trackers/dri/../../../../../../src/gallium/state_trackers/dri/dri_context.c:194

addr2line 0x2977f2 -e /usr/lib/x86_64-linux-gnu/dri/r600_dri.so 
/build/buildd/mesa-10.3~git1408111930.904ed3+gallium/build/dri/src/mesa/drivers/dri/common/../../../../../../../src/mesa/drivers/dri/common/dri_util.c:487

-- 
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/20140811/9d42f34b/attachment-0001.html>

Implementing the accelerated DRI/DRM driver for a pure 2D graphics card?

[Keith Packard]

Tom Li  writes:

> So I just stuck at here. Is there a standard way to just let
> userspace/DDX to access the 2D drawing processor by the exported
> interface or DRI/DRM layer?

The Intel UXA driver uses the 2D engine for simple X acceleration
through the kernel DRI/GEM interfaces. The portion of that interface
designed to support accelerated graphics operations is entirely
GPU-specific, so you would design that based on how your card works, and
the resulting 2D driver would be chipset specific as well, using the
custom kernel interfaces you create.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/8cbce307/attachment.sig>

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

--- Comment #10 from Grzegorz Kowal  ---
No lockups for me after applying the patch. Thanks!

-- 
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/20140811/66fba82a/attachment.html>

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

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

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

--- Comment #19 from Clemens Fruhwirth  ---
I still see crashes linux-3.15.18 and ati-dri 10.2.5.

-- 
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/20140811/24f2f500/attachment.html>

How to design a DRM KMS driver exposing 2D compositing?

[Daniel Vetter]

On Mon, Aug 11, 2014 at 10:16:24AM -0700, Eric Anholt wrote:
> Daniel Vetter  writes:
> 
> > On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> >> Hi,
> >> 
> >> there is some hardware than can do 2D compositing with an arbitrary
> >> number of planes. I'm not sure what the absolute maximum number of
> >> planes is, but for the discussion, let's say it is 100.
> >> 
> >> There are many complicated, dynamic constraints on how many, what size,
> >> etc. planes can be used at once. A driver would be able to check those
> >> before kicking the 2D compositing engine.
> >> 
> >> The 2D compositing engine in the best case (only few planes used) is
> >> able to composite on the fly in scanout, just like the usual overlay
> >> hardware blocks in CRTCs. When the composition complexity goes up, the
> >> driver can fall back to compositing into a buffer rather than on the
> >> fly in scanout. This fallback needs to be completely transparent to the
> >> user space, implying only additional latency if anything.
> >> 
> >> These 2D compositing features should be exposed to user space through a
> >> standard kernel ABI, hopefully an existing ABI in the very near future
> >> like the KMS atomic.
> >
> > I presume we're talking about the video core from raspi? Or at least
> > something similar?
> 
> Pekka wasn't sure if things were confidential here, but I can say it:
> Yeah, it's the RPi.
> 
> While I haven't written code using the compositor interface (I just did
> enough to shim in a single plane for bringup, and I'm hoping Pekka and
> company can handle the rest for me :) ), my understanding is that the
> way you make use of it is that you've got your previous frame loaded up
> in the HVS (the plane compositor hardware), then when you're asked to
> put up a new frame that's going to be too hard, you take some
> complicated chunk of your scene and ask the HVS to use any spare
> bandwidth it has while it's still scanning out the previous frame in
> order to composite that piece of new scene into memory.  Then, when it's
> done with the offline composite, you ask the HVS to do the next scanout
> frame using the original scene with the pre-composited temporary buffer.
> 
> I'm pretty comfortable with the idea of having some large number of
> planes preallocated, and deciding that "nobody could possibly need more
> than 16" (or whatever).
> 
> My initial reaction to "we should just punt when we run out of bandwidth
> and have a special driver interface for offline composite" was "that's
> awful, when the kernel could just get the job done immediately, and
> easily, and it would know exactly what it needed to composite to get
> things to fit (unlike userspace)".  I'm trying to come up with what
> benefit there would be to having a separate interface for offline
> composite.  I've got 3 things:
> 
> - Avoids having a potentially long, interruptible wait in the modeset
>   path while the offline composite happens.  But I think we have other
>   interruptible waits in that path alreaady.
> 
> - Userspace could potentially do something else besides use the HVS to
>   get the fallback done.  Video would have to use the HVS, to get the
>   same scaling filters applied as the previous frame where things *did*
>   fit, but I guess you could composite some 1:1 RGBA overlays in GL,
>   which would have more BW available to it than what you're borrowing
>   from the previous frame's HVS capacity.
> 
> - Userspace could potentially use the offline composite interface for
>   things besides just the running-out-of-bandwidth case.  Like, it was
>   doing a nicely-filtered downscale of an overlaid video, then the user
>   hit pause and walked away: you could have a timeout that noticed that
>   the complicated scene hadn't changed in a while, and you'd drop from
>   overlays to a HVS-composited single plane to reduce power.
> 
> The third one is the one I've actually found kind of compelling, and
> might be switching me from wanting no userspace visibility into the
> fallback.  But I don't have a good feel for how much complexity there is
> to our descriptions of planes, and how much poorly-tested interface we'd
> be adding to support this usecase.

Compositor should already do a rough bw guesstimate and if stuff doesn't
change any more bake the entire scene into a single framebuffer. The exact
same issue happens on more usual hw with video overlays, too.

Ofc if it turns out that scanning out your yuv planes is less bw then the
overlay shouldn't be stopped ofc. But imo there's nothing special here for
the rpi.

> (Because, honestly, I don't expect the fallbacks to be hit much -- my
> understanding of the bandwidth equation is that you're mostly counting
> the number of pixels that have to be read, and clipped-out pixels
> because somebody's overlaid on top of you don't count unless they're in
> the same burst read.  So unless people are going nuts with blending in
> overlays, or downscaled video, it's probably not a problem,

[Bug 82473] No picture

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

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

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg and xorg logs directly to the bug.  Is this a
regression?  If so when was it last working?  Can you get a picture of the
screen?  Does using a non-HDMI (e.g., DVI) connector help?  Does booting with
radeon.audio=0 on the kernel command line in grub help?

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

How to design a DRM KMS driver exposing 2D compositing?

[Daniel Vetter]

On Mon, Aug 11, 2014 at 07:09:11PM +0300, Ville Syrj?l? wrote:
> On Mon, Aug 11, 2014 at 05:35:31PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 11, 2014 at 03:47:22PM +0300, Pekka Paalanen wrote:
> > > > > What if I cannot even pick a maximum number of planes, but wanted to
> > > > > (as the hardware allows) let the 2D compositing scale up basically
> > > > > unlimited while becoming just slower and slower?
> > > > > 
> > > > > I think at that point one would be looking at a rendering API really,
> > > > > rather than a KMS API, so it's probably out of scope. Where is the 
> > > > > line
> > > > > between KMS 2D compositing with planes vs. 2D composite rendering?
> > > > 
> > > > I think kms should still be real-time compositing - if you have to
> > > > internally render to a buffer and then scan that one out due to lack of
> > > > memory bandwidth or so that very much sounds like a rendering api. Ofc
> > > > stuff like writeback buffers blurry that a bit. But hw writeback is 
> > > > still
> > > > real-time.
> > > 
> > > Agreed, that's a good and clear definition, even if it might make my
> > > life harder.
> > > 
> > > I'm still not completely sure, that using an intermediate buffer means
> > > sacrificing real-time (i.e. being able to hit the next vblank the user
> > > space is aiming for) performance, maybe the 2D engine output rate
> > > fluctuates so that the scanout block would have problems but a buffer
> > > can still be completed in time. Anyway, details.
> > > 
> > > Would using an intermediate buffer be ok if we can still maintain
> > > real-time? That is, say, if a compositor kicks the atomic update e.g.
> > > 7 ms before vblank, we would still hit it even with the intermediate
> > > buffer? If that is actually possible, I don't know yet.
> > 
> > I guess you could hide this in the kernel if you want. After all the
> > entire point of kms is to shovel the memory management into the kernel
> > driver's responsibility. But I agree with Rob that if there are
> > intermediate buffers, it would be fairly neat to let userspace know about
> > them.
> > 
> > So I don't think the intermediate buffer thing would be a no-go for kms,
> > but I suspect that will only happen when the videocore can't hit the next
> > frame reliably. And that kind of stutter is imo not good for a kms driver.
> > I guess you could forgo vblank timestamp support and just go with
> > super-variable scanout times, but I guess that will make the video
> > playback people unhappy - they already bitch about the sub 1% inaccuracy
> > we have in our hdmi clocks.
> > 
> > > > > Should I really be designing a driver-specific compositing API 
> > > > > instead,
> > > > > similar to what the Mesa OpenGL implementations use? Then have user
> > > > > space maybe use the user space driver part via OpenWFC perhaps?
> > > > > And when I mention OpenWFC, you probably notice, that I am not aware 
> > > > > of
> > > > > any standard user space API I could be implementing here. ;-)
> > > > 
> > > > Personally I'd expose a bunch of planes with kms (enough so that you can
> > > > reap the usual benefits planes bring wrt video-playback and stuff like
> > > > that). So perhaps something in line with what current hw does in hw and
> > > > then double it a bit or twice - 16 planes or so. Your driver would 
> > > > reject
> > > > any requests that need intermediate buffers to store render results. 
> > > > I.e.
> > > > everything that can't be scanned out directly in real-time at about 
> > > > 60fps.
> > > > The fun with kms planes is also that right now we have 0 standards for
> > > > z-ordering and blending. So would need to define that first.
> > > 
> > > I do not yet know where that real-time limit is, but I'm guessing it
> > > could be pretty low. If it is, we might start hitting software
> > > compositing (like Pixman) very often, which is too slow to be usable.
> > 
> > Well for other drivers/stacks we'd fall back to GL compositing. pixman
> > would obviously be terribly. Curious question: Can you provoke the
> > hw/firmware to render into abitrary buffers or does it only work together
> > with real display outputs?
> > 
> > So I guess the real question is: What kind of interface does videocore
> > provide? Note that kms framebuffers are super-flexible and you're freee to
> > add your own ioctl for special framebuffers which are rendered live by the
> > vc. So that might be a possible way to expose this if you can't tell the
> > vc which buffers to render into explicitly.
> 
> We should maybe think about exposing this display engine writeback
> stuff in some decent way. Maybe a property on the crtc (or plane when
> doing per-plane writeback) where you attach a target framebuffer for
> the write. And some virtual connectors/encoders to satisfy the kms API
> requirements.
> 
> With DSI command mode I suppose it would be possible to even mix display
> and writeback uses of the same hardware pipeline so that the writeback
> doesn't disturb the displa

[Bug 76321] Incorrect hwmon temperature when radeon card is turned off

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

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

--- Comment #11 from Alex Deucher  ---
Applied to my tree.  thanks.

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

[Bug 82473] New: No picture

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

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

  Priority: medium
Bug ID: 82473
  Assignee: dri-devel at lists.freedesktop.org
   Summary: No picture
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: dimangi42 at gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: XOrg CVS
 Component: DRM/Radeon
   Product: DRI

At boot, I get only a striped screen, no decent picture.

Kernel 3.13
dmesg http://paste.ubuntu.com/8019782/
Xorg.0.log http://paste.ubuntu.com/8019790/

Kernel 3.15
dmesg http://paste.ubuntu.com/8019797/
Xorg.0.log http://paste.ubuntu.com/8019803/

Kernel 3.16
dmesg http://paste.ubuntu.com/8019829/
Xorg.0.log http://paste.ubuntu.com/8019826/

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

How to design a DRM KMS driver exposing 2D compositing?

[Ville Syrjälä]

On Mon, Aug 11, 2014 at 05:35:31PM +0200, Daniel Vetter wrote:
> On Mon, Aug 11, 2014 at 03:47:22PM +0300, Pekka Paalanen wrote:
> > > > What if I cannot even pick a maximum number of planes, but wanted to
> > > > (as the hardware allows) let the 2D compositing scale up basically
> > > > unlimited while becoming just slower and slower?
> > > > 
> > > > I think at that point one would be looking at a rendering API really,
> > > > rather than a KMS API, so it's probably out of scope. Where is the line
> > > > between KMS 2D compositing with planes vs. 2D composite rendering?
> > > 
> > > I think kms should still be real-time compositing - if you have to
> > > internally render to a buffer and then scan that one out due to lack of
> > > memory bandwidth or so that very much sounds like a rendering api. Ofc
> > > stuff like writeback buffers blurry that a bit. But hw writeback is still
> > > real-time.
> > 
> > Agreed, that's a good and clear definition, even if it might make my
> > life harder.
> > 
> > I'm still not completely sure, that using an intermediate buffer means
> > sacrificing real-time (i.e. being able to hit the next vblank the user
> > space is aiming for) performance, maybe the 2D engine output rate
> > fluctuates so that the scanout block would have problems but a buffer
> > can still be completed in time. Anyway, details.
> > 
> > Would using an intermediate buffer be ok if we can still maintain
> > real-time? That is, say, if a compositor kicks the atomic update e.g.
> > 7 ms before vblank, we would still hit it even with the intermediate
> > buffer? If that is actually possible, I don't know yet.
> 
> I guess you could hide this in the kernel if you want. After all the
> entire point of kms is to shovel the memory management into the kernel
> driver's responsibility. But I agree with Rob that if there are
> intermediate buffers, it would be fairly neat to let userspace know about
> them.
> 
> So I don't think the intermediate buffer thing would be a no-go for kms,
> but I suspect that will only happen when the videocore can't hit the next
> frame reliably. And that kind of stutter is imo not good for a kms driver.
> I guess you could forgo vblank timestamp support and just go with
> super-variable scanout times, but I guess that will make the video
> playback people unhappy - they already bitch about the sub 1% inaccuracy
> we have in our hdmi clocks.
> 
> > > > Should I really be designing a driver-specific compositing API instead,
> > > > similar to what the Mesa OpenGL implementations use? Then have user
> > > > space maybe use the user space driver part via OpenWFC perhaps?
> > > > And when I mention OpenWFC, you probably notice, that I am not aware of
> > > > any standard user space API I could be implementing here. ;-)
> > > 
> > > Personally I'd expose a bunch of planes with kms (enough so that you can
> > > reap the usual benefits planes bring wrt video-playback and stuff like
> > > that). So perhaps something in line with what current hw does in hw and
> > > then double it a bit or twice - 16 planes or so. Your driver would reject
> > > any requests that need intermediate buffers to store render results. I.e.
> > > everything that can't be scanned out directly in real-time at about 60fps.
> > > The fun with kms planes is also that right now we have 0 standards for
> > > z-ordering and blending. So would need to define that first.
> > 
> > I do not yet know where that real-time limit is, but I'm guessing it
> > could be pretty low. If it is, we might start hitting software
> > compositing (like Pixman) very often, which is too slow to be usable.
> 
> Well for other drivers/stacks we'd fall back to GL compositing. pixman
> would obviously be terribly. Curious question: Can you provoke the
> hw/firmware to render into abitrary buffers or does it only work together
> with real display outputs?
> 
> So I guess the real question is: What kind of interface does videocore
> provide? Note that kms framebuffers are super-flexible and you're freee to
> add your own ioctl for special framebuffers which are rendered live by the
> vc. So that might be a possible way to expose this if you can't tell the
> vc which buffers to render into explicitly.

We should maybe think about exposing this display engine writeback
stuff in some decent way. Maybe a property on the crtc (or plane when
doing per-plane writeback) where you attach a target framebuffer for
the write. And some virtual connectors/encoders to satisfy the kms API
requirements.

With DSI command mode I suppose it would be possible to even mix display
and writeback uses of the same hardware pipeline so that the writeback
doesn't disturb the display. But I'm not sure there would any nice way
to expose that in kms. Maybe just expose two crtcs, one for writeback
and one for display and multiplex in the driver.

-- 
Ville Syrj?l?
Intel OTC

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Rob Clark]

On Mon, Aug 11, 2014 at 4:53 PM, David Rientjes  wrote:
> On Mon, 11 Aug 2014, sanjeev sharma wrote:
>
>> Hello David,
>>
>> Here is the old discussion carried out on this.
>>
>> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802
>>
>
> I'm suggesting that if you don't want to incur the cost of the conditional
> everytime you call a certain function with assert_spin_locked() that you
> could covert these to lockdep_assert_held() so the check is only done when
> lockdep is enabled for debugging.

not sure about the nouveau parts, but for the omap and msm hunks, this
code getting called at potentially vblank rate (so maybe once or twice
per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
so I don't always have it enabled.  So it sounds like for those two at
least assert_spin_locked() is a better option.

BR,
-R

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

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

--- Comment #9 from Andy Furniss  ---
(In reply to comment #7)
> (In reply to comment #4)

> > Will test more tonight, but I managed to crash without uvd (just -vo vdpau)
> > last night - though my mplayer also had some issues.
> 
> I had the same behaviour. With the patch from attachment 104443 [details]
> [review] applied though, everything is back to normal again.

Yes, tested now and the patch does fix for it me.

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

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

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

--- Comment #8 from Henri Verbeet  ---
(In reply to comment #7)
> Looks like this is happening purely for testing if a fpu control word would
> be preserved, the actual value used by d3d does disable them just fine
> (though, of course, this could also happen on any app, not just wine, if it
> unmasks exceptions before calling into mesa code).
It's perhaps important to point out that Wine isn't a single application as
such, and we don't have a lot of control over how individual applications setup
the FPU. The test in question exists because some applications expect us to
setup the FPU in a specific way, while others expect us to leave it alone.
Without having looked much into the llvm source for the backtrace, it's perhaps
also a bit odd that compiling a pass-through shader is doing anything involving
denormals in the first place.

> Though IIRC you aren't actually expected to leave the fpu control word in a
> non-standard state when you're calling into library code, so I'm not really
> sure if this qualifies as a mesa bug. In any way since this happens in llvm
> code finally here it might even be a bug there. I guess the only way to fix
Mostly just for reference, regressions every now and then aside, the Wine D3D
tests pretty much just pass with r600g / sb; that's currently my main
development setup. (And somewhat off-topic, but not entirely unrelated to this
bug, the reason that that's not a radeonsi system is because I think the llvm
dependency is just painful to work with.)

-- 
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/20140811/8e57cb91/attachment.html>

[Intel-gfx] [PATCH 2/7] drm/i915: Renaming DP training vswing pre emph defines

[Damien Lespiau]

On Fri, Aug 08, 2014 at 04:23:41PM +0530, sonika.jindal at intel.com wrote:
> From: Sonika Jindal 
> 
> Rename the defines to have levels instead of values for vswing and
> pre-emph levels as the values may differ in other scenarios like low vswing of
> eDP1.4 where the values are different.
> 
> Done using following cocci patch for each define:
> @@
> @@
> 
>  # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
> + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
> 
> ...
> 
> Signed-off-by: Sonika Jindal 

Reviewed-by: Damien Lespiau 

-- 
Damien

> ---
>  drivers/gpu/drm/i915/intel_bios.c |   16 +--
>  drivers/gpu/drm/i915/intel_dp.c   |  194 
> ++---
>  2 files changed, 105 insertions(+), 105 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 031c565..e871f68 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -627,16 +627,16 @@ parse_edp(struct drm_i915_private *dev_priv, struct 
> bdb_header *bdb)
>  
>   switch (edp_link_params->preemphasis) {
>   case EDP_PREEMPHASIS_NONE:
> - dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_0;
> + dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_0;
>   break;
>   case EDP_PREEMPHASIS_3_5dB:
> - dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_3_5;
> + dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_1;
>   break;
>   case EDP_PREEMPHASIS_6dB:
> - dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_6;
> + dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_2;
>   break;
>   case EDP_PREEMPHASIS_9_5dB:
> - dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPHASIS_9_5;
> + dev_priv->vbt.edp_preemphasis = DP_TRAIN_PRE_EMPH_LEVEL_3;
>   break;
>   default:
>   DRM_DEBUG_KMS("VBT has unknown eDP pre-emphasis value %u\n",
> @@ -646,16 +646,16 @@ parse_edp(struct drm_i915_private *dev_priv, struct 
> bdb_header *bdb)
>  
>   switch (edp_link_params->vswing) {
>   case EDP_VSWING_0_4V:
> - dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_400;
> + dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_0;
>   break;
>   case EDP_VSWING_0_6V:
> - dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_600;
> + dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_1;
>   break;
>   case EDP_VSWING_0_8V:
> - dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_800;
> + dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
>   break;
>   case EDP_VSWING_1_2V:
> - dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_1200;
> + dev_priv->vbt.edp_vswing = DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
>   break;
>   default:
>   DRM_DEBUG_KMS("VBT has unknown eDP voltage swing value %u\n",
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 34e3c47..01f264c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2381,13 +2381,13 @@ intel_dp_voltage_max(struct intel_dp *intel_dp)
>   enum port port = dp_to_dig_port(intel_dp)->port;
>  
>   if (IS_VALLEYVIEW(dev))
> - return DP_TRAIN_VOLTAGE_SWING_1200;
> + return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
>   else if (IS_GEN7(dev) && port == PORT_A)
> - return DP_TRAIN_VOLTAGE_SWING_800;
> + return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
>   else if (HAS_PCH_CPT(dev) && port != PORT_A)
> - return DP_TRAIN_VOLTAGE_SWING_1200;
> + return DP_TRAIN_VOLTAGE_SWING_LEVEL_3;
>   else
> - return DP_TRAIN_VOLTAGE_SWING_800;
> + return DP_TRAIN_VOLTAGE_SWING_LEVEL_2;
>  }
>  
>  static uint8_t
> @@ -2398,49 +2398,49 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
> uint8_t voltage_swing)
>  
>   if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
>   switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> - case DP_TRAIN_VOLTAGE_SWING_400:
> - return DP_TRAIN_PRE_EMPHASIS_9_5;
> - case DP_TRAIN_VOLTAGE_SWING_600:
> - return DP_TRAIN_PRE_EMPHASIS_6;
> - case DP_TRAIN_VOLTAGE_SWING_800:
> - return DP_TRAIN_PRE_EMPHASIS_3_5;
> - case DP_TRAIN_VOLTAGE_SWING_1200:
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> + return DP_TRAIN_PRE_EMPH_LEVEL_3;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
> + return DP_TRAIN_PRE_EMPH_LEVEL_2;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
> + return DP_TRAIN_PRE_EMPH_LEVEL_1;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_3:
>   def

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

--- Comment #8 from Marek Ol??k  ---
(In reply to comment #4)
> Created attachment 104443 [details] [review]
> Possible fix
> 
> That patch should do the trick. Please test.

Sorry about that.

Reviewed-by: Marek Ol??k 

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

[Intel-gfx] [PATCH 1/7] drm: Renaming DP training vswing pre emph defines

[Damien Lespiau]

On Fri, Aug 08, 2014 at 04:23:40PM +0530, sonika.jindal at intel.com wrote:
> From: Sonika Jindal 
> 
> Adding new defines, older one will be removed in the last patch in the series.
> This is to rename the defines to have levels instead of values for vswing and
> pre-emph levels as the values may differ in other scenarios like low vswing of
> eDP1.4 where the values are different.
> 
> Done using following cocci patch for each define:
> @@
> @@
> 
>  # define DP_TRAIN_VOLTAGE_SWING_400 (0 << 0)
> + # define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
> 
> ...
> Cc: dri-devel at lists.freedesktop.org
> 
> Signed-off-by: Sonika Jindal 


Reviewed-by: Damien Lespiau 

-- 
Damien

> ---
>  include/drm/drm_dp_helper.h |8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index a21568b..3840a05 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -191,15 +191,23 @@
>  # define DP_TRAIN_VOLTAGE_SWING_SHIFT0
>  # define DP_TRAIN_MAX_SWING_REACHED  (1 << 2)
>  # define DP_TRAIN_VOLTAGE_SWING_400  (0 << 0)
> +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_0 (0 << 0)
>  # define DP_TRAIN_VOLTAGE_SWING_600  (1 << 0)
> +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_1 (1 << 0)
>  # define DP_TRAIN_VOLTAGE_SWING_800  (2 << 0)
> +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_2 (2 << 0)
>  # define DP_TRAIN_VOLTAGE_SWING_1200 (3 << 0)
> +# define DP_TRAIN_VOLTAGE_SWING_LEVEL_3 (3 << 0)
>  
>  # define DP_TRAIN_PRE_EMPHASIS_MASK  (3 << 3)
>  # define DP_TRAIN_PRE_EMPHASIS_0 (0 << 3)
> +# define DP_TRAIN_PRE_EMPH_LEVEL_0   (0 << 3)
>  # define DP_TRAIN_PRE_EMPHASIS_3_5   (1 << 3)
> +# define DP_TRAIN_PRE_EMPH_LEVEL_1   (1 << 3)
>  # define DP_TRAIN_PRE_EMPHASIS_6 (2 << 3)
> +# define DP_TRAIN_PRE_EMPH_LEVEL_2   (2 << 3)
>  # define DP_TRAIN_PRE_EMPHASIS_9_5   (3 << 3)
> +# define DP_TRAIN_PRE_EMPH_LEVEL_3   (3 << 3)
>  
>  # define DP_TRAIN_PRE_EMPHASIS_SHIFT 3
>  # define DP_TRAIN_MAX_PRE_EMPHASIS_REACHED  (1 << 5)
> -- 
> 1.7.10.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Michel Dänzer]

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.


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

How to design a DRM KMS driver exposing 2D compositing?

[Daniel Vetter]

On Mon, Aug 11, 2014 at 03:47:22PM +0300, Pekka Paalanen wrote:
> > > What if I cannot even pick a maximum number of planes, but wanted to
> > > (as the hardware allows) let the 2D compositing scale up basically
> > > unlimited while becoming just slower and slower?
> > > 
> > > I think at that point one would be looking at a rendering API really,
> > > rather than a KMS API, so it's probably out of scope. Where is the line
> > > between KMS 2D compositing with planes vs. 2D composite rendering?
> > 
> > I think kms should still be real-time compositing - if you have to
> > internally render to a buffer and then scan that one out due to lack of
> > memory bandwidth or so that very much sounds like a rendering api. Ofc
> > stuff like writeback buffers blurry that a bit. But hw writeback is still
> > real-time.
> 
> Agreed, that's a good and clear definition, even if it might make my
> life harder.
> 
> I'm still not completely sure, that using an intermediate buffer means
> sacrificing real-time (i.e. being able to hit the next vblank the user
> space is aiming for) performance, maybe the 2D engine output rate
> fluctuates so that the scanout block would have problems but a buffer
> can still be completed in time. Anyway, details.
> 
> Would using an intermediate buffer be ok if we can still maintain
> real-time? That is, say, if a compositor kicks the atomic update e.g.
> 7 ms before vblank, we would still hit it even with the intermediate
> buffer? If that is actually possible, I don't know yet.

I guess you could hide this in the kernel if you want. After all the
entire point of kms is to shovel the memory management into the kernel
driver's responsibility. But I agree with Rob that if there are
intermediate buffers, it would be fairly neat to let userspace know about
them.

So I don't think the intermediate buffer thing would be a no-go for kms,
but I suspect that will only happen when the videocore can't hit the next
frame reliably. And that kind of stutter is imo not good for a kms driver.
I guess you could forgo vblank timestamp support and just go with
super-variable scanout times, but I guess that will make the video
playback people unhappy - they already bitch about the sub 1% inaccuracy
we have in our hdmi clocks.

> > > Should I really be designing a driver-specific compositing API instead,
> > > similar to what the Mesa OpenGL implementations use? Then have user
> > > space maybe use the user space driver part via OpenWFC perhaps?
> > > And when I mention OpenWFC, you probably notice, that I am not aware of
> > > any standard user space API I could be implementing here. ;-)
> > 
> > Personally I'd expose a bunch of planes with kms (enough so that you can
> > reap the usual benefits planes bring wrt video-playback and stuff like
> > that). So perhaps something in line with what current hw does in hw and
> > then double it a bit or twice - 16 planes or so. Your driver would reject
> > any requests that need intermediate buffers to store render results. I.e.
> > everything that can't be scanned out directly in real-time at about 60fps.
> > The fun with kms planes is also that right now we have 0 standards for
> > z-ordering and blending. So would need to define that first.
> 
> I do not yet know where that real-time limit is, but I'm guessing it
> could be pretty low. If it is, we might start hitting software
> compositing (like Pixman) very often, which is too slow to be usable.

Well for other drivers/stacks we'd fall back to GL compositing. pixman
would obviously be terribly. Curious question: Can you provoke the
hw/firmware to render into abitrary buffers or does it only work together
with real display outputs?

So I guess the real question is: What kind of interface does videocore
provide? Note that kms framebuffers are super-flexible and you're freee to
add your own ioctl for special framebuffers which are rendered live by the
vc. So that might be a possible way to expose this if you can't tell the
vc which buffers to render into explicitly.

> Defining z-order and blending sounds like peanuts compared to below.
> 
> > Then expose everything else with a separate api. I guess you'll just end
> > up with per-compositor userspace drivers due to the lack of a widespread
> > 2d api. OpenVG is kinda dead, and cairo might not fit.
> 
> Yeah, that is kind of the worst case, which also seems unavoidable.

Yeah, there's no universal 2d accel standard at all. Which sucks for hw
that can't do full gl.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

Hello David,

Here is the old discussion carried out on this.

http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802

Regards
Sanjeev Sharma


On Mon, Aug 11, 2014 at 5:31 PM, sanjeev sharma  wrote:

> Hello David,
>
> Do you see any problem in replacing with assert_spin_locked() and here is
> old discusion  around the
>
>
>
> On Mon, Aug 11, 2014 at 5:15 PM, David Rientjes 
> wrote:
>
>> On Sun, 10 Aug 2014, Guenter Roeck wrote:
>>
>> > spin_is_locked() always returns false in uniprocessor configurations
>> > and can therefore not be used with BUG_ON. Replace it with
>> > assert_spin_locked(), which exists for that very purpose.
>> >
>>
>> It may be helpful to assess whether any of these sites should be converted
>> to lockdep_assert_held() so they have no cost when lockdep isn't enabled
>> but still reveal problems when debugging.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/87a70c32/attachment-0001.html>

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

Hello David,

Do you see any problem in replacing with assert_spin_locked() and here is
old discusion  around the



On Mon, Aug 11, 2014 at 5:15 PM, David Rientjes  wrote:

> On Sun, 10 Aug 2014, Guenter Roeck wrote:
>
> > spin_is_locked() always returns false in uniprocessor configurations
> > and can therefore not be used with BUG_ON. Replace it with
> > assert_spin_locked(), which exists for that very purpose.
> >
>
> It may be helpful to assess whether any of these sites should be converted
> to lockdep_assert_held() so they have no cost when lockdep isn't enabled
> but still reveal problems when debugging.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/aaa44903/attachment-0001.html>

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

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

--- Comment #7 from Roland Scheidegger  ---
Specifically it looks like the wine test actually tries a control word which
enables all fpu exceptions.
Seems like nvidia drivers had the same problem at some point:
http://bugs.winehq.org/show_bug.cgi?id=28634
Looks like this is happening purely for testing if a fpu control word would be
preserved, the actual value used by d3d does disable them just fine (though, of
course, this could also happen on any app, not just wine, if it unmasks
exceptions before calling into mesa code).
I vaguely remember similar issues in the past in other parts of mesa code.
Though IIRC you aren't actually expected to leave the fpu control word in a
non-standard state when you're calling into library code, so I'm not really
sure if this qualifies as a mesa bug. In any way since this happens in llvm
code finally here it might even be a bug there. I guess the only way to fix
this kind of bug in mesa would be to change the fpu control word on all entry
points which could trigger numerical exceptions (and when additionally also
consistent results are on the wish list, would need to change it on all
entrypoints which could do some fpu calculations)) which I think is not
reasonable.

-- 
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/20140811/137673de/attachment.html>

How to design a DRM KMS driver exposing 2D compositing?

[Daniel Vetter]

On Mon, Aug 11, 2014 at 09:32:32AM -0400, Rob Clark wrote:
> On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter  wrote:
> > Personally I'd expose a bunch of planes with kms (enough so that you can
> > reap the usual benefits planes bring wrt video-playback and stuff like
> > that). So perhaps something in line with what current hw does in hw and
> > then double it a bit or twice - 16 planes or so. Your driver would reject
> > any requests that need intermediate buffers to store render results. I.e.
> > everything that can't be scanned out directly in real-time at about 60fps.
> > The fun with kms planes is also that right now we have 0 standards for
> > z-ordering and blending. So would need to define that first.
> >
> > Then expose everything else with a separate api. I guess you'll just end
> > up with per-compositor userspace drivers due to the lack of a widespread
> > 2d api. OpenVG is kinda dead, and cairo might not fit.
> 
> I kind of suspect someone should really just design weston2d, an api
> more explicitly for compositing.. model after OpenWFC if that fits
> nicely.  Or not if it doesn't.  Or just use the existing weston
> front-end/back-end split..
> 
> I expect other wayland compositors would want more or less the same
> thing as weston (barring pre-existing layer-cake mess..  cough, cough,
> cogl/clutter/gnome-shell..)
> 
> We could even make a gallium statetracker implementation of weston2d
> to get some usage on desktop..

There's vega already in mesa  It just looks terribly unused.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014? 08? 11? 16:50, Thierry Reding wrote:
> On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
>> On 2014? 08? 11? 16:24, Thierry Reding wrote:
>>> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
 On 2014? 08? 08? 18:55, Thierry Reding wrote:
> [...]
> The above is actually more like this:
>
>   if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
>   clear DSI_HS_CLK_CTRL;
>   else
>   set DSI_HS_CLK_CTRL;
>
>   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
>   clear DSI_HIGH_SPEED_TRANS;
>   else
>   set DSI_HIGH_SPEED_TRANS;
>
> So for peripherals that don't support non-continuous clock mode, this
> will result in the following for low-power transmissions:
>
>   clear DSI_HS_CLK_CTRL; /* HS clock always on */
>   clear DSI_HIGH_SPEED_TRANS;

 Right, then how host driver should check it if peripheral doesn't
 support non-continuous clock mode? Or how the peripheral should notify
 it to host driver? It would need a new flag instead of
 MIPI_DSI_MODE_NON_CONTINUOUS.
>>>
>>> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
>>> set to signal that they support non-continuous mode. If devices don't
>>> have that set, then the controller should always provide the HS clock.
>>>
>>> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
>>> does *not* support non-continuous mode.
>>>
>>
>> Again, assume that there is a peripheral that doesn't support
>> non-continuous clock mode but host driver want to transmit data in low
>> power. For this, you already mentioned like below,
>>
>> "So for peripherals that don't support non-continuous clock mode, this
>> will result in the following for low-power transmissions:
>>
>>  clear DSI_HS_CLK_CTRL; /* HS clock always on */
>>  clear DSI_HIGH_SPEED_TRANS;
>> "
>>
>> In this case, how should host driver check it to clear above two flags?
>> As you know, this is required to clear two flags same as non-continuous
>> clock mode. Don't you think that we need a new flag to identify them -
>> non-continuous clock mode or just for low-power transmission?
> 
> See what I wrote a little further up:
> 
>   if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
>   clear DSI_HS_CLK_CTRL;
>   else
>   set DSI_HS_CLK_CTRL;
>
>   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
>   clear DSI_HIGH_SPEED_TRANS;
>   else
>   set DSI_HIGH_SPEED_TRANS;
>
> 
> MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non-
> continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because
> that tells the controller to turn off the HS clock between high-speed
> transmissions.
> 
> MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power
> mode.
> 
> With the above two flags we can cover four cases:
> 
>   1) non-continuous mode with messages transmitted in low-power mode
>   2) non-continuous mode with messages transmitted in high-speed mode
>   3) continuous mode with messages transmitted in low-power mode

In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear
DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but
dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right.
You mean that continuous mode is set by default implicitly?

Thanks,
Inki Dae

>   4) continuous mode with messages transmitted in high-speed mode
> 
> What other cases do you think we need to support?
> 
> Thierry
> 

[Bug 76321] Incorrect hwmon temperature when radeon card is turned off

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

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

Pali Roh?r  changed:

   What|Removed |Added

 Attachment #146011|0   |1
is obsolete||

--- Comment #10 from Pali Roh?r  ---
Created attachment 146241
  --> https://bugzilla.kernel.org/attachment.cgi?id=146241&action=edit
patch v2 for get/set dpm state

New patch v2 without changes to
radeon_[get|set]_dpm_forced_performance_level().

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

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014? 08? 11? 16:44, Andrzej Hajda wrote:
> On 08/11/2014 09:09 AM, Inki Dae wrote:
>> On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
>>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
 On 08/08/2014 09:37 AM, Inki Dae wrote:
> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 22:55, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 22:17, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 20:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 18:09, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 15:58, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> 2014-08-06 16:43 GMT+09:00 Thierry Reding  gmail.com>:
>> [...]
>> As far as I can tell non-continuous mode simply means that 
>> the host can
>> turn off the HS clock after a high-speed transmission. I 
>> think Andrzej
>> mentioned this already in another subthread, but this is an 
>> optional
>> mode that peripherals can support if they have extra 
>> circuitry that
>> provides an internal clock. Peripherals that don't have such 
>> circuitry
>> may rely on the HS clock to perform in between transmissions 
>> and
>> therefore require the HS clock to be always on (continuous 
>> mode). That's
>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it 
>> advertises that the
>> peripheral supports non-continuous mode and therefore the 
>> host can turn
>> the HS clock off after high-speed transmissions.
> What I don't make sure is this sentence. With
> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
> operations.
> One is,
> 1. host controller will generates signals if a bit of a 
> register
> related to non-contiguous clock mode is set or unset.
> 2. And then video data is transmitted to panel in HS mode.
> 3. And then D-PHY detects LP-11 signal (positive and negative 
> lane all
> are high).
> 4. And then D-PHY disables HS clock of host controller.
> 5. At this time, operation mode of host controller becomes 
> LPM.
>
> Other is,
> 1. host controller will generates signals if a bit of a 
> register
> related to non-contiguous clock mode is set or unset.
> 2. And then D-PHY detects LP-11 signal (positive and negative 
> lane all
> are high).
> 3. And then video data is transmitted to panel in LPM.
> 4. At this time, operation mode of host controller becomes 
> LPM.
>
> It seems that you says latter case.
 No. High speed clock and low power mode are orthogonal. 
 Non-continuous
 mode simply means that the clock lane enters LP-11 between HS
 transmissions (see 5.6 "Clock Management" of the DSI 
 specification).

>>> It seems that clock lane enters LP-11 regardless of HS clock 
>>> enabled if
>>> non-continous mode is used. Right?
>> No, I think as long as HS clock is enabled the clock lane won't 
>> enter
>> LP-11. Non-continuous mode means that the controller can disable 
>> the HS
>> clock between HS transmissions. So in non-continuous mode the 
>> clock lane
>> can enter LP-11 because the controller disables the HS clock.
> It makes me a little bit confusing. You said "if HS clock is 
> enabled,
> the the clock lane won't enter LP-11" But you said again "the 
> clock lane
> can enter LP-11 because the controller disables the HS clock" 
> What is
> the meaning?
 It means that if the HS clock is enabled, then the clock lane is 
 not in
 LP-11. When the HS clock stops, then the clock lane enters LP-11.

>> In continuous mode, then the clock will never be disabled, hence 
>> the
>> clock 

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

Kai  changed:

   What|Removed |Added

 CC||kai at dev.carbon-project.org

--- Comment #7 from Kai  ---
(In reply to comment #4)
> Created attachment 104443
> Possible fix
> 
> That patch should do the trick. Please test.

You can have my
  Tested-by: Kai Wasserb?ch 
on this. I saw the same issue without the patch.

(In reply to comment #6)
> (In reply to comment #4)
> > Created attachment 104443
> > Possible fix
> > 
> > That patch should do the trick. Please test.
> 
> Will test more tonight, but I managed to crash without uvd (just -vo vdpau)
> last night - though my mplayer also had some issues.

I had the same behaviour. With the patch from attachment 104443 applied though,
everything is back to normal again.

-- 
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/20140811/6e5ebe58/attachment.html>

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

--- Comment #6 from Andy Furniss  ---
(In reply to comment #4)
> Created attachment 104443 [details] [review]
> Possible fix
> 
> That patch should do the trick. Please test.

Will test more tonight, but I managed to crash without uvd (just -vo vdpau)
last night - though my mplayer also had some issues.

I am not sure something that only touches uvd is enough, but I haven't got time
to test 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/20140811/115d06e4/attachment.html>

[Bug 76321] Incorrect hwmon temperature when radeon card is turned off

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

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

--- Comment #9 from Alex Deucher  ---
(In reply to Pali Roh?r from comment #8)
> Created attachment 146011 [details]
> patch for get/set dpm state
> 
> 
> It is implemented in attached patch. I tested it and it working fine on my
> system. My scripts automacitally change dpm state to battery when power
> adapter is unplugged. And when radeon card is powered on it initialize in
> battery state (even if last state was performance before turning card off).

Patch looks fine wth respect to the power state change.  You can drop the
changes to radeon_[get|set]_dpm_forced_performance_level() however.  That won't
work without changes to the current force_performance_level interfaces.  If you
can clean up the patch as requested and generate a proper git patch, I'll apply
it.

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

How to design a DRM KMS driver exposing 2D compositing?

[Pekka Paalanen]

On Mon, 11 Aug 2014 14:14:56 +0100
Damien Lespiau  wrote:

> On Mon, Aug 11, 2014 at 03:07:33PM +0300, Pekka Paalanen wrote:
> > > > there is some hardware than can do 2D compositing with an arbitrary
> > > > number of planes. I'm not sure what the absolute maximum number of
> > > > planes is, but for the discussion, let's say it is 100.
> > > > 
> > > > There are many complicated, dynamic constraints on how many, what size,
> > > > etc. planes can be used at once. A driver would be able to check those
> > > > before kicking the 2D compositing engine.
> > > > 
> > > > The 2D compositing engine in the best case (only few planes used) is
> > > > able to composite on the fly in scanout, just like the usual overlay
> > > > hardware blocks in CRTCs. When the composition complexity goes up, the
> > > > driver can fall back to compositing into a buffer rather than on the
> > > > fly in scanout. This fallback needs to be completely transparent to the
> > > > user space, implying only additional latency if anything.
> > > 
> > > This looks like a fallback that would use GL to compose the intermediate
> > > buffer. Any reason why that fallback can't be kicked from userspace?
> > 
> > It is not GL, and GL might not be available or desireable. It is still
> > the same 2D compositing engine in hardware, but now running with
> > off-screen target buffer, because it cannot anymore keep up with the
> > continous pixel rate that the direct scanout would need.
> 
> I didn't mean this was GL, but just making the parallel, ie. we wouldn't
> put a GL fallback into the kernel.
> 
> > If we were to use the 2D compositing engine from user space, we would
> > be on the road to OpenWFC. IOW, there is no standard API for the
> > user space to use yet, as far as I'm aware. ;-)
> > 
> > I'm just trying to avoid having to design a kernel driver ABI for a
> > user space driver, then design/implement some standard user space
> > API on top, and then go fix all compositors to actually use it instead
> > of / with KMS.
> 
> It's no easy trade-off. For instance, if the compositor doesn't know
> about some of the hw constraints you are talking about, it may ask the
> kernel for a configuration that suddently will only allow 20 fps updates
> (because of the bw limitation you're mentioning). And the compositor
> just wouldn't know.

Sure, but it would still be much better than the actual fallback in the
compositor in user space, if we cannot drive the 2D engine from user
space.

KMS works the same way already: if you have GL rendering that just
runs for too long, your final pageflip using it will implicitly get
delayed that much. Does it not?

> I can only speak for the hw I know, if you want to squeeze everything
> you can from that simple (compared to the one you're talking about)
> display hw, there's no choice, the compositor needs to know about the
> constraints to make clever decisions (that's what we do on Android). But
> then the appeal of a common interface is understandable.
> 
> (An answer that doesn't actually say anything interesting, oh well),

Yeah... so it comes down to deciding at what point will the kernel
driver say "this won't fly, do something else". And danvet has a pretty
solid answer to that, I think.


Thanks,
pq

Radeon: [TTM] Failed to find memory space for buffer [...] eviction

[Michel Dänzer]

On 08.08.2014 21:48, Thomas Schwinge wrote:
> 
> I recetly repurposed a BlueMedia OPTIMA II system, Biostar MCP6P M2+
> mainboard, AMD Athlon II X2 215 with 2700 MHz, 8 GiB RAM, Xen setup, for
> use as a desktop machine (the Xen dom0, specifically).  I put in a
> Sapphire Radeon HD 4350 card where I'm connecting the DVI output to a
> portrait-oriented (1200x1920) and the VGA output to a landscape-oriented
> (1440x900) monitor.  I'm running Debian GNU/Linux testing with the
> Cinnamon desktop environment (Gnome Shell derivate of Gnome 2).  This is
> being used as a development and all-purpose system, that is, several
> virtual desktops, with mostly full-screen terminal/Emacs/web browser
> processes running.  This is working nicely.
> 
> However, what happens after (irregularely) several hours of usage is that
> any interactions involving the desktop get executed very sluggishly
> (initially about 1 s of delay, later getting worse), which makes this
> unworkable.  Once this happens, I see the following in dmesg, repeating
> every once in a while:
> 
> [96450.514927] [TTM] Failed to find memory space for buffer 
> 0x88015daef048 eviction
> [96450.514934] [TTM] No space for 88015daef048 (65536 pages, 262144K, 
> 256M)
> [96450.514936] [TTM]   placement[0]=0x00410002 (1)
> [96450.514938] [TTM] has_type: 1
> [96450.514939] [TTM] use_type: 1
> [96450.514940] [TTM] flags: 0x000A
> [96450.514941] [TTM] gpu_offset: 0x2000
> [96450.514942] [TTM] size: 262144
> [96450.514943] [TTM] available_caching: 0x0007
> [96450.514944] [TTM] default_caching: 0x0001
> [96450.514947] [TTM]  0x-0x0001:1: used
> [96450.514949] [TTM]  0x0001-0x0011:   16: used
> [96450.514951] [TTM]  0x0011-0x0111:  256: used
> [96450.514952] [TTM]  0x0111-0x0121:   16: used
> [96450.514953] [TTM]  0x0121-0x0122:1: used
> [96450.514955] [TTM]  0x0122-0x0222:  256: used
> [96450.514956] [TTM]  0x0222-0x030f:  237: free
> [96450.514957] [TTM]  0x030f-0x0313:4: used
> [96450.514958] [TTM]  0x0313-0x61c0:24237: free
> [96450.514960] [TTM]  0x61c0-0x000161c0:65536: used
> [96450.514961] [TTM]  0x000161c0-0x000242fe:57662: free
> [96450.514962] [TTM]  0x000242fe-0x000342fe:65536: used
> [96450.514963] [TTM]  0x000342fe-0x0003d80c:38158: free
> [96450.514965] [TTM]  0x0003d80c-0x0003d90c:  256: used
> [96450.514966] [TTM]  0x0003d90c-0x0003ff94: 9864: free
> [96450.514967] [TTM]  0x0003ff94-0x0003ffa4:   16: used
> [96450.514969] [TTM]  0x0003ffa4-0x0004:   92: free
> [96450.514970] [TTM]  total: 262144, used 131894 free 130250

Looks like it's failing to evict a buffer object (BO) of size 256MB,
presumably from VRAM.

AFAICT there's only 256MB of GTT available, is this an AGP card? If so,
does radeon.agpmode=-1 on the kernel command line help?

If not, increasing the GTT size further using radeon.gartsize=1024 or
even larger powers of two might help.

Though I wonder if one of the apps you're running really needs a BO of
size 256MB, or maybe just thinks it's a good idea to use a texture of
the maximum size supported by OpenGL...


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

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 234 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/d4d0b01d/attachment.sig>

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Mon, 11 Aug 2014, Rob Clark wrote:

> > I'm suggesting that if you don't want to incur the cost of the conditional
> > everytime you call a certain function with assert_spin_locked() that you
> > could covert these to lockdep_assert_held() so the check is only done when
> > lockdep is enabled for debugging.
> 
> not sure about the nouveau parts, but for the omap and msm hunks, this
> code getting called at potentially vblank rate (so maybe once or twice
> per ~16ms)..  and lockdep has considerable overhead (for a gpu driver)
> so I don't always have it enabled.  So it sounds like for those two at
> least assert_spin_locked() is a better option.
> 

Unless there's a bug, assert_spin_locked() is just going to incur an 
unnecessary cost every time it is called at runtime.  My suggestion was to 
limit that check only to debugging kernels that include enabling lockdep 
when tracking down problems rather than needlessly evaluating the 
conditional every time when there are no bugs.

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014? 08? 11? 16:24, Thierry Reding wrote:
> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
>> On 2014? 08? 08? 18:55, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
 On 2014? 08? 08? 16:03, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 22:55, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 22:17, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 20:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 18:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 15:58, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
 2014-08-06 16:43 GMT+09:00 Thierry Reding >>> gmail.com>:
> [...]
> As far as I can tell non-continuous mode simply means that 
> the host can
> turn off the HS clock after a high-speed transmission. I 
> think Andrzej
> mentioned this already in another subthread, but this is an 
> optional
> mode that peripherals can support if they have extra 
> circuitry that
> provides an internal clock. Peripherals that don't have such 
> circuitry
> may rely on the HS clock to perform in between transmissions 
> and
> therefore require the HS clock to be always on (continuous 
> mode). That's
> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
> that the
> peripheral supports non-continuous mode and therefore the 
> host can turn
> the HS clock off after high-speed transmissions.

 What I don't make sure is this sentence. With
 MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
 operations.
 One is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then video data is transmitted to panel in HS mode.
 3. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 4. And then D-PHY disables HS clock of host controller.
 5. At this time, operation mode of host controller becomes LPM.

 Other is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 3. And then video data is transmitted to panel in LPM.
 4. At this time, operation mode of host controller becomes LPM.

 It seems that you says latter case.
>>>
>>> No. High speed clock and low power mode are orthogonal. 
>>> Non-continuous
>>> mode simply means that the clock lane enters LP-11 between HS
>>> transmissions (see 5.6 "Clock Management" of the DSI 
>>> specification).
>>>
>>
>> It seems that clock lane enters LP-11 regardless of HS clock 
>> enabled if
>> non-continous mode is used. Right?
>
> No, I think as long as HS clock is enabled the clock lane won't 
> enter
> LP-11. Non-continuous mode means that the controller can disable 
> the HS
> clock between HS transmissions. So in non-continuous mode the 
> clock lane
> can enter LP-11 because the controller disables the HS clock.

 It makes me a little bit confusing. You said "if HS clock is 
 enabled,
 the the clock lane won't enter LP-11" But you said again "the 
 clock lane
 can enter LP-11 because the controller disables the HS clock" What 
 is
 the meaning?
>>>
>>> It means that if the HS clock is enabled, then the clock lane is 
>>> not in
>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>
> In continuous mode, then the clock will never be disabled, hence 
> the
> clock lane will never enter LP-11.
>
>

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
>> On 08/08/2014 09:37 AM, Inki Dae wrote:
>>> On 2014? 08? 08? 16:03, Thierry Reding wrote:
 On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
> On 2014? 08? 07? 22:55, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 22:17, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 20:09, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 18:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 15:58, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>>> 2014-08-06 16:43 GMT+09:00 Thierry Reding >> gmail.com>:
 [...]
 As far as I can tell non-continuous mode simply means that the 
 host can
 turn off the HS clock after a high-speed transmission. I think 
 Andrzej
 mentioned this already in another subthread, but this is an 
 optional
 mode that peripherals can support if they have extra circuitry 
 that
 provides an internal clock. Peripherals that don't have such 
 circuitry
 may rely on the HS clock to perform in between transmissions 
 and
 therefore require the HS clock to be always on (continuous 
 mode). That's
 what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
 that the
 peripheral supports non-continuous mode and therefore the host 
 can turn
 the HS clock off after high-speed transmissions.
>>> What I don't make sure is this sentence. With
>>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
>>> operations.
>>> One is,
>>> 1. host controller will generates signals if a bit of a register
>>> related to non-contiguous clock mode is set or unset.
>>> 2. And then video data is transmitted to panel in HS mode.
>>> 3. And then D-PHY detects LP-11 signal (positive and negative 
>>> lane all
>>> are high).
>>> 4. And then D-PHY disables HS clock of host controller.
>>> 5. At this time, operation mode of host controller becomes LPM.
>>>
>>> Other is,
>>> 1. host controller will generates signals if a bit of a register
>>> related to non-contiguous clock mode is set or unset.
>>> 2. And then D-PHY detects LP-11 signal (positive and negative 
>>> lane all
>>> are high).
>>> 3. And then video data is transmitted to panel in LPM.
>>> 4. At this time, operation mode of host controller becomes LPM.
>>>
>>> It seems that you says latter case.
>> No. High speed clock and low power mode are orthogonal. 
>> Non-continuous
>> mode simply means that the clock lane enters LP-11 between HS
>> transmissions (see 5.6 "Clock Management" of the DSI 
>> specification).
>>
> It seems that clock lane enters LP-11 regardless of HS clock 
> enabled if
> non-continous mode is used. Right?
 No, I think as long as HS clock is enabled the clock lane won't 
 enter
 LP-11. Non-continuous mode means that the controller can disable 
 the HS
 clock between HS transmissions. So in non-continuous mode the 
 clock lane
 can enter LP-11 because the controller disables the HS clock.
>>> It makes me a little bit confusing. You said "if HS clock is 
>>> enabled,
>>> the the clock lane won't enter LP-11" But you said again "the clock 
>>> lane
>>> can enter LP-11 because the controller disables the HS clock" What 
>>> is
>>> the meaning?
>> It means that if the HS clock is enabled, then the clock lane is not 
>> in
>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>
 In continuous mode, then the clock will never be disabled, hence 
 the
 clock lane will never enter LP-11.

> And also it seems that non-continous mode is different from LPM 
> at all
> because with non-continuous mode, command data is transmitted to 
> panel
> in HS mode, but with LPM, command data is transmitted to panel in 
> LP

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

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||madcatx at atlas.cz

--- Comment #85 from Alex Deucher  ---
*** Bug 79231 has been marked as a duplicate of this bug. ***

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

[Bug 82376] radeonsi: Monitors on HDMI not recognized with xrandr on Radeon HD 7700 (Cape Verde)

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

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

--- Comment #5 from Alex Deucher  ---
How are you connecting your monitor(s) to the ports on the graphics card?  Does
the same monitor work when connected via DVI rather than HDMI or were you
testing different monitors on the different ports?  Are you sure your HDMI
cable is good?

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

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

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

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

--- Comment #84 from Pali Roh?r  ---
Created attachment 104448
  --> https://bugs.freedesktop.org/attachment.cgi?id=104448&action=edit
diff between my patch and patch from comment #74

I commented lines

si_pm4_set_reg(pm4, GRBM_GFX_INDEX, SE_INDEX(i) | SH_BROADCAST_WRITES);

and

si_pm4_set_reg(pm4, GRBM_GFX_INDEX, SE_BROADCAST_WRITES);

in patch from comment #74 and my radeon hd 7730 started working :-) glamor and
opengl3 working fine.

In attchment is diff between my patch and patch from comment #74.

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

How to design a DRM KMS driver exposing 2D compositing?

[Pekka Paalanen]

Hi Daniel,

you make perfect sense as usual. :-)
Comments below.

On Mon, 11 Aug 2014 14:06:36 +0200
Daniel Vetter  wrote:

> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> > Hi,
> > 
> > there is some hardware than can do 2D compositing with an arbitrary
> > number of planes. I'm not sure what the absolute maximum number of
> > planes is, but for the discussion, let's say it is 100.
> > 
> > There are many complicated, dynamic constraints on how many, what size,
> > etc. planes can be used at once. A driver would be able to check those
> > before kicking the 2D compositing engine.
> > 
> > The 2D compositing engine in the best case (only few planes used) is
> > able to composite on the fly in scanout, just like the usual overlay
> > hardware blocks in CRTCs. When the composition complexity goes up, the
> > driver can fall back to compositing into a buffer rather than on the
> > fly in scanout. This fallback needs to be completely transparent to the
> > user space, implying only additional latency if anything.
> > 
> > These 2D compositing features should be exposed to user space through a
> > standard kernel ABI, hopefully an existing ABI in the very near future
> > like the KMS atomic.
> 
> I presume we're talking about the video core from raspi? Or at least
> something similar?

Yes.

> > Assuming the DRM universal planes and atomic mode setting / page flip
> > infrastructure is in place, could the 2D compositing capabilities be
> > exposed through universal planes? We can assume that plane properties
> > are enough to describe all the compositing parameters.
> > 
> > Atomic updates are needed so that the complicated constraints can be
> > checked, and user space can try to reduce the composition complexity if
> > the kernel driver sees that it won't work.
> > 
> > Would it be feasible to generate a hundred identical non-primary planes
> > to be exposed to user space via DRM?
> > 
> > If that could be done, the kernel driver could just use the existing
> > kernel/user ABIs without having to invent something new, and programs
> > like a Wayland compositor would not need to be coded specifically for
> > this hardware.
> > 
> > What problems do you see with this plan?
> > Are any of those problems unfixable or simply prohibitive?
> > 
> > I have some concerns, which I am not sure will actually be a problem:
> > - Does allocating a 100 planes eat too much kernel memory?
> >   I mean just the bookkeeping, properties, etc.
> > - Would such an amount of planes make some in-kernel algorithms slow
> >   (particularly in DRM common code)?
> > - Considering how user space discovers all DRM resources, would this
> >   make a compositor "slow" to start?
> 
> I don't see any problem with that. We have a few plane-loops, but iirc
> those can be easily fixed to use indices and similar stuff. The atomic
> ioctl itself should scale nicely.

Very nice.

> > I suppose whether these turn out to be prohibitive or not, one just has
> > to implement it and see. It should be usable on a slowish CPU with
> > unimpressive amounts of RAM, because that is where a separate 2D
> > compositing engine gives the most kick.
> > 
> > FWIW, dynamically created/destroyed planes would probably not be the
> > answer. The kernel driver cannot decide before-hand how many planes it
> > can expose. How many planes can be used depends completely on how user
> > space decides to use them. Therefore I believe it should expose the
> > maximum number always, whether there is any real use case that could
> > actually get them all running or not.
> 
> Yeah dynamic planes doesn't sound like a nice solution, least because
> you'll get to audit piles of code. Currently really only framebuffers (and
> to some extent connectors) can come and go freely in kms-land.

Yup, thought so.

> > What if I cannot even pick a maximum number of planes, but wanted to
> > (as the hardware allows) let the 2D compositing scale up basically
> > unlimited while becoming just slower and slower?
> > 
> > I think at that point one would be looking at a rendering API really,
> > rather than a KMS API, so it's probably out of scope. Where is the line
> > between KMS 2D compositing with planes vs. 2D composite rendering?
> 
> I think kms should still be real-time compositing - if you have to
> internally render to a buffer and then scan that one out due to lack of
> memory bandwidth or so that very much sounds like a rendering api. Ofc
> stuff like writeback buffers blurry that a bit. But hw writeback is still
> real-time.

Agreed, that's a good and clear definition, even if it might make my
life harder.

I'm still not completely sure, that using an intermediate buffer means
sacrificing real-time (i.e. being able to hit the next vblank the user
space is aiming for) performance, maybe the 2D engine output rate
fluctuates so that the scanout block would have problems but a buffer
can still be completed in time. Anyway, details.

Would using an intermediate buffer b

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

--- Comment #5 from smoki  ---
(In reply to comment #4)
> Created attachment 104443 [details] [review]
> Possible fix
> 
> That patch should do the trick. Please test.

 Works for me, thanks Christian.

-- 
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/20140811/5c19ff4c/attachment.html>

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

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

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

--- Comment #14 from Eugene  ---
I have some difficulties getting bt (don't know why):

Starting program: /usr/lib/firefox/firefox 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe9be4700 (LWP 4870)]
[Thread 0x7fffe9be4700 (LWP 4870) exited]
[New Thread 0x7fffe9be4700 (LWP 4873)]
[New Thread 0x7fffe2eff700 (LWP 4874)]
[New Thread 0x7fffe1ee6700 (LWP 4875)]
[New Thread 0x7fffe16e5700 (LWP 4876)]
[New Thread 0x7fffe0aff700 (LWP 4877)]
[New Thread 0x7fffdeed0700 (LWP 4880)]
[New Thread 0x7fffde4ff700 (LWP 4881)]
[New Thread 0x7fffe3030700 (LWP 4882)]
[New Thread 0x7fffdd5ff700 (LWP 4883)]
[New Thread 0x7fffdc7ff700 (LWP 4884)]
[New Thread 0x7fffe0ee4700 (LWP 4885)]
[New Thread 0x7fffde6cf700 (LWP 4886)]
[New Thread 0x7fffddcfe700 (LWP 4887)]
[New Thread 0x7fffdcdfe700 (LWP 4888)]
[New Thread 0x7fffc17ff700 (LWP 4889)]
[New Thread 0x7fffc09ff700 (LWP 4890)]
[New Thread 0x7fffc03ff700 (LWP 4891)]
[New Thread 0x7fffbfbfe700 (LWP 4892)]
[New Thread 0x7fffbf3fd700 (LWP 4893)]
[New Thread 0x7fffbebfc700 (LWP 4894)]
[New Thread 0x7fffbe1ff700 (LWP 4895)]
[New Thread 0x7fffbd9fe700 (LWP 4896)]
[Thread 0x7fffdc7ff700 (LWP 4884) exited]
[New Thread 0x7fffbcfff700 (LWP 4897)]
[Thread 0x7fffbf3fd700 (LWP 4893) exited]
[Thread 0x7fffbebfc700 (LWP 4894) exited]
[New Thread 0x7fffbc7fe700 (LWP 4898)]
[New Thread 0x7fffdc7ff700 (LWP 4899)]
[New Thread 0x7fffbf3fd700 (LWP 4900)]
[Thread 0x7fffdc7ff700 (LWP 4899) exited]
[Thread 0x7fffbfbfe700 (LWP 4892) exited]
[Thread 0x7fffbf3fd700 (LWP 4900) exited]
[New Thread 0x7fffbf3fd700 (LWP 4901)]
[Thread 0x7fffbf3fd700 (LWP 4901) exited]
[New Thread 0x7fffbf3fd700 (LWP 4902)]
[Thread 0x7fffbc7fe700 (LWP 4898) exited]
[New Thread 0x7fffbc7fe700 (LWP 4903)]
[New Thread 0x7fffdc7ff700 (LWP 4904)]
[Thread 0x7fffbf3fd700 (LWP 4902) exited]
[Thread 0x7fffbc7fe700 (LWP 4903) exited]
[New Thread 0x7fffbf3fd700 (LWP 4905)]
[New Thread 0x7fffbc7fe700 (LWP 4906)]
[New Thread 0x7fffbfbfe700 (LWP 4907)]

Program received signal SIGSEGV, Segmentation fault.
PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
716/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h: ?
?? ? ??? .
Quit
#0  PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
No locals.
#1  js::jit::JitRuntime::patchIonBackedges (this=, rt=, target=target at entry=js::jit::JitRuntime::BackedgeLoopHeader) at
/build/buildd/firefox-31.0+build1/js/src/jit/Ion.cpp:412
iter = {iter = 0x7fffbaaec5e0}
#2  0x732cab85 in js::jit::InterruptCheck (cx=0x7fffde553480) at
/build/buildd/firefox-31.0+build1/js/src/jit/VMFunctions.cpp:523
No locals.
#3  0x77e5627a in ?? ()
No symbol table info available.
#4  0x7fff78b8 in ?? ()
No symbol table info available.
#5  0x7fff7840 in ?? ()
No symbol table info available.
#6  0x754f0840 in DeepCloneObjectLiteralInfo () from
/usr/lib/firefox/libxul.so
No symbol table info available.
#7  0x7fffe0d34880 in ?? ()
No symbol table info available.
#8  0x7fffdb8e8b59 in ?? ()
No symbol table info available.
#9  0x0601 in ?? ()
No symbol table info available.
#10 0x7fff78b8 in ?? ()
No symbol table info available.
#11 0xfffbe0b77700 in ?? ()
No symbol table info available.
#12 0xfffbdb721b00 in ?? ()
No symbol table info available.
#13 0x24a0f352d0012900 in ?? ()
No symbol table info available.
#14 0x7fff7990 in ?? ()
No symbol table info available.
#15 0xfff88058 in ?? ()
No symbol table info available.
#16 0x7fffdb730a80 in ?? ()
No symbol table info available.
#17 0x in ?? ()
No symbol table info available.
Quit


P.S. libgl1-mesa-dri-dbg and firefox-dbg is definitely installed.

Any suggestions ?

-- 
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/20140811/943129ce/attachment-0001.html>

[Bug 82376] radeonsi: Monitors on HDMI not recognized with xrandr on Radeon HD 7700 (Cape Verde)

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

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

--- Comment #4 from Jean-Fran?ois Fortin Tam  ---
Hi, after some more testing (on my current kernel, 3.15) it seems that booting
with HDMI plugged in does not work either, so there's no difference between
that and hotplugging.

The dmesg and xorg logs were already in the downstream report:
  xorg log: https://bugzilla.redhat.com/attachment.cgi?id=812727
  dmesg: https://bugzilla.redhat.com/attachment.cgi?id=812728
  lspci -: https://bugzilla.redhat.com/attachment.cgi?id=812729

-- 
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/20140811/22e25830/attachment.html>

[Bug 82376] radeonsi: Monitors on HDMI not recognized with xrandr on Radeon HD 7700 (Cape Verde)

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

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

--- Comment #3 from Alex Deucher  ---
Please attach this information after booting with the monitor attached and
after hotplugging.

-- 
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/20140811/2318a8fe/attachment-0001.html>

[Bug 82376] radeonsi: Monitors on HDMI not recognized with xrandr on Radeon HD 7700 (Cape Verde)

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

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

--- Comment #2 from Alex Deucher  ---
Please attach your dmesg output and xorg log.

-- 
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/20140811/8dfdf30e/attachment.html>

How to design a DRM KMS driver exposing 2D compositing?

[Pekka Paalanen]

On Mon, 11 Aug 2014 11:57:10 +0100
Damien Lespiau  wrote:

> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> > Hi,
> 
> Hi,
> 
> > there is some hardware than can do 2D compositing with an arbitrary
> > number of planes. I'm not sure what the absolute maximum number of
> > planes is, but for the discussion, let's say it is 100.
> > 
> > There are many complicated, dynamic constraints on how many, what size,
> > etc. planes can be used at once. A driver would be able to check those
> > before kicking the 2D compositing engine.
> > 
> > The 2D compositing engine in the best case (only few planes used) is
> > able to composite on the fly in scanout, just like the usual overlay
> > hardware blocks in CRTCs. When the composition complexity goes up, the
> > driver can fall back to compositing into a buffer rather than on the
> > fly in scanout. This fallback needs to be completely transparent to the
> > user space, implying only additional latency if anything.
> 
> This looks like a fallback that would use GL to compose the intermediate
> buffer. Any reason why that fallback can't be kicked from userspace?

It is not GL, and GL might not be available or desireable. It is still
the same 2D compositing engine in hardware, but now running with
off-screen target buffer, because it cannot anymore keep up with the
continous pixel rate that the direct scanout would need.

If we were to use the 2D compositing engine from user space, we would
be on the road to OpenWFC. IOW, there is no standard API for the
user space to use yet, as far as I'm aware. ;-)

I'm just trying to avoid having to design a kernel driver ABI for a
user space driver, then design/implement some standard user space
API on top, and then go fix all compositors to actually use it instead
of / with KMS.


Thanks,
pq

[PATCH] Add missing lines to ci_set_thermal_temperature_range

[Alex Deucher]

On Mon, Aug 11, 2014 at 1:53 PM, Oleg Chernovskiy  
wrote:
> Signed-off-by: Oleg Chernovskiy 

Applied to my fixes tree.  Thanks!

Alex

> ---
>  drivers/gpu/drm/radeon/ci_dpm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 022561e..d416bb2 100644
> --- a/drivers/gpu/drm/radeon/ci_dpm.c
> +++ b/drivers/gpu/drm/radeon/ci_dpm.c
> @@ -869,6 +869,9 @@ static int ci_set_thermal_temperature_range(struct 
> radeon_device *rdev,
> WREG32_SMC(CG_THERMAL_CTRL, tmp);
>  #endif
>
> +   rdev->pm.dpm.thermal.min_temp = low_temp;
> +   rdev->pm.dpm.thermal.max_temp = high_temp;
> +
> return 0;
>  }
>
> --
> 2.0.4
>

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

--- Comment #4 from Christian K?nig  ---
Created attachment 104443
  --> https://bugs.freedesktop.org/attachment.cgi?id=104443&action=edit
Possible fix

That patch should do the trick. Please test.

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

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014? 08? 08? 18:55, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
>> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
 On 2014? 08? 07? 22:55, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 22:17, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 20:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 18:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 15:58, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
>> 2014-08-06 16:43 GMT+09:00 Thierry Reding > gmail.com>:
>>> [...]
>>> As far as I can tell non-continuous mode simply means that the 
>>> host can
>>> turn off the HS clock after a high-speed transmission. I think 
>>> Andrzej
>>> mentioned this already in another subthread, but this is an 
>>> optional
>>> mode that peripherals can support if they have extra circuitry 
>>> that
>>> provides an internal clock. Peripherals that don't have such 
>>> circuitry
>>> may rely on the HS clock to perform in between transmissions and
>>> therefore require the HS clock to be always on (continuous 
>>> mode). That's
>>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
>>> that the
>>> peripheral supports non-continuous mode and therefore the host 
>>> can turn
>>> the HS clock off after high-speed transmissions.
>>
>> What I don't make sure is this sentence. With
>> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
>> operations.
>> One is,
>> 1. host controller will generates signals if a bit of a register
>> related to non-contiguous clock mode is set or unset.
>> 2. And then video data is transmitted to panel in HS mode.
>> 3. And then D-PHY detects LP-11 signal (positive and negative 
>> lane all
>> are high).
>> 4. And then D-PHY disables HS clock of host controller.
>> 5. At this time, operation mode of host controller becomes LPM.
>>
>> Other is,
>> 1. host controller will generates signals if a bit of a register
>> related to non-contiguous clock mode is set or unset.
>> 2. And then D-PHY detects LP-11 signal (positive and negative 
>> lane all
>> are high).
>> 3. And then video data is transmitted to panel in LPM.
>> 4. At this time, operation mode of host controller becomes LPM.
>>
>> It seems that you says latter case.
>
> No. High speed clock and low power mode are orthogonal. 
> Non-continuous
> mode simply means that the clock lane enters LP-11 between HS
> transmissions (see 5.6 "Clock Management" of the DSI 
> specification).
>

 It seems that clock lane enters LP-11 regardless of HS clock 
 enabled if
 non-continous mode is used. Right?
>>>
>>> No, I think as long as HS clock is enabled the clock lane won't 
>>> enter
>>> LP-11. Non-continuous mode means that the controller can disable 
>>> the HS
>>> clock between HS transmissions. So in non-continuous mode the clock 
>>> lane
>>> can enter LP-11 because the controller disables the HS clock.
>>
>> It makes me a little bit confusing. You said "if HS clock is enabled,
>> the the clock lane won't enter LP-11" But you said again "the clock 
>> lane
>> can enter LP-11 because the controller disables the HS clock" What is
>> the meaning?
>
> It means that if the HS clock is enabled, then the clock lane is not 
> in
> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>
>>> In continuous mode, then the clock will never be disabled, hence the
>>> clock lane will never enter LP-11.
>>>
 And also it seems that non-continous mode is different from LPM at 
 all
 because with non-continuous mode, command data is transmitted to 
 panel
 in HS mode, but with LPM, command data is transmitted to panel in 
 LP
 mode. Also right?
>>>
>>> No. I think you can send command data to the periph

How to design a DRM KMS driver exposing 2D compositing?

[Damien Lespiau]

On Mon, Aug 11, 2014 at 03:07:33PM +0300, Pekka Paalanen wrote:
> > > there is some hardware than can do 2D compositing with an arbitrary
> > > number of planes. I'm not sure what the absolute maximum number of
> > > planes is, but for the discussion, let's say it is 100.
> > > 
> > > There are many complicated, dynamic constraints on how many, what size,
> > > etc. planes can be used at once. A driver would be able to check those
> > > before kicking the 2D compositing engine.
> > > 
> > > The 2D compositing engine in the best case (only few planes used) is
> > > able to composite on the fly in scanout, just like the usual overlay
> > > hardware blocks in CRTCs. When the composition complexity goes up, the
> > > driver can fall back to compositing into a buffer rather than on the
> > > fly in scanout. This fallback needs to be completely transparent to the
> > > user space, implying only additional latency if anything.
> > 
> > This looks like a fallback that would use GL to compose the intermediate
> > buffer. Any reason why that fallback can't be kicked from userspace?
> 
> It is not GL, and GL might not be available or desireable. It is still
> the same 2D compositing engine in hardware, but now running with
> off-screen target buffer, because it cannot anymore keep up with the
> continous pixel rate that the direct scanout would need.

I didn't mean this was GL, but just making the parallel, ie. we wouldn't
put a GL fallback into the kernel.

> If we were to use the 2D compositing engine from user space, we would
> be on the road to OpenWFC. IOW, there is no standard API for the
> user space to use yet, as far as I'm aware. ;-)
> 
> I'm just trying to avoid having to design a kernel driver ABI for a
> user space driver, then design/implement some standard user space
> API on top, and then go fix all compositors to actually use it instead
> of / with KMS.

It's no easy trade-off. For instance, if the compositor doesn't know
about some of the hw constraints you are talking about, it may ask the
kernel for a configuration that suddently will only allow 20 fps updates
(because of the bw limitation you're mentioning). And the compositor
just wouldn't know.

I can only speak for the hw I know, if you want to squeeze everything
you can from that simple (compared to the one you're talking about)
display hw, there's no choice, the compositor needs to know about the
constraints to make clever decisions (that's what we do on Android). But
then the appeal of a common interface is understandable.

(An answer that doesn't actually say anything interesting, oh well),

-- 
Damien

How to design a DRM KMS driver exposing 2D compositing?

[Daniel Vetter]

On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> Hi,
> 
> there is some hardware than can do 2D compositing with an arbitrary
> number of planes. I'm not sure what the absolute maximum number of
> planes is, but for the discussion, let's say it is 100.
> 
> There are many complicated, dynamic constraints on how many, what size,
> etc. planes can be used at once. A driver would be able to check those
> before kicking the 2D compositing engine.
> 
> The 2D compositing engine in the best case (only few planes used) is
> able to composite on the fly in scanout, just like the usual overlay
> hardware blocks in CRTCs. When the composition complexity goes up, the
> driver can fall back to compositing into a buffer rather than on the
> fly in scanout. This fallback needs to be completely transparent to the
> user space, implying only additional latency if anything.
> 
> These 2D compositing features should be exposed to user space through a
> standard kernel ABI, hopefully an existing ABI in the very near future
> like the KMS atomic.

I presume we're talking about the video core from raspi? Or at least
something similar?

> Assuming the DRM universal planes and atomic mode setting / page flip
> infrastructure is in place, could the 2D compositing capabilities be
> exposed through universal planes? We can assume that plane properties
> are enough to describe all the compositing parameters.
> 
> Atomic updates are needed so that the complicated constraints can be
> checked, and user space can try to reduce the composition complexity if
> the kernel driver sees that it won't work.
> 
> Would it be feasible to generate a hundred identical non-primary planes
> to be exposed to user space via DRM?
> 
> If that could be done, the kernel driver could just use the existing
> kernel/user ABIs without having to invent something new, and programs
> like a Wayland compositor would not need to be coded specifically for
> this hardware.
> 
> What problems do you see with this plan?
> Are any of those problems unfixable or simply prohibitive?
> 
> I have some concerns, which I am not sure will actually be a problem:
> - Does allocating a 100 planes eat too much kernel memory?
>   I mean just the bookkeeping, properties, etc.
> - Would such an amount of planes make some in-kernel algorithms slow
>   (particularly in DRM common code)?
> - Considering how user space discovers all DRM resources, would this
>   make a compositor "slow" to start?

I don't see any problem with that. We have a few plane-loops, but iirc
those can be easily fixed to use indices and similar stuff. The atomic
ioctl itself should scale nicely.

> I suppose whether these turn out to be prohibitive or not, one just has
> to implement it and see. It should be usable on a slowish CPU with
> unimpressive amounts of RAM, because that is where a separate 2D
> compositing engine gives the most kick.
> 
> FWIW, dynamically created/destroyed planes would probably not be the
> answer. The kernel driver cannot decide before-hand how many planes it
> can expose. How many planes can be used depends completely on how user
> space decides to use them. Therefore I believe it should expose the
> maximum number always, whether there is any real use case that could
> actually get them all running or not.

Yeah dynamic planes doesn't sound like a nice solution, least because
you'll get to audit piles of code. Currently really only framebuffers (and
to some extent connectors) can come and go freely in kms-land.

> What if I cannot even pick a maximum number of planes, but wanted to
> (as the hardware allows) let the 2D compositing scale up basically
> unlimited while becoming just slower and slower?
> 
> I think at that point one would be looking at a rendering API really,
> rather than a KMS API, so it's probably out of scope. Where is the line
> between KMS 2D compositing with planes vs. 2D composite rendering?

I think kms should still be real-time compositing - if you have to
internally render to a buffer and then scan that one out due to lack of
memory bandwidth or so that very much sounds like a rendering api. Ofc
stuff like writeback buffers blurry that a bit. But hw writeback is still
real-time.

> Should I really be designing a driver-specific compositing API instead,
> similar to what the Mesa OpenGL implementations use? Then have user
> space maybe use the user space driver part via OpenWFC perhaps?
> And when I mention OpenWFC, you probably notice, that I am not aware of
> any standard user space API I could be implementing here. ;-)

Personally I'd expose a bunch of planes with kms (enough so that you can
reap the usual benefits planes bring wrt video-playback and stuff like
that). So perhaps something in line with what current hw does in hw and
then double it a bit or twice - 16 planes or so. Your driver would reject
any requests that need intermediate buffers to store render results. I.e.
everything that can't be scanned out directly in real-time a

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Mon, 11 Aug 2014, sanjeev sharma wrote:

> Hello David,
> 
> Here is the old discussion carried out on this.
> 
> http://linux-kernel.2935.n7.nabble.com/Is-spin-is-locked-safe-to-use-with-BUG-ON-WARN-ON-td654800.html#a921802
> 

I'm suggesting that if you don't want to incur the cost of the conditional 
everytime you call a certain function with assert_spin_locked() that you 
could covert these to lockdep_assert_held() so the check is only done when 
lockdep is enabled for debugging.

How to design a DRM KMS driver exposing 2D compositing?

[Pekka Paalanen]

Hi,

there is some hardware than can do 2D compositing with an arbitrary
number of planes. I'm not sure what the absolute maximum number of
planes is, but for the discussion, let's say it is 100.

There are many complicated, dynamic constraints on how many, what size,
etc. planes can be used at once. A driver would be able to check those
before kicking the 2D compositing engine.

The 2D compositing engine in the best case (only few planes used) is
able to composite on the fly in scanout, just like the usual overlay
hardware blocks in CRTCs. When the composition complexity goes up, the
driver can fall back to compositing into a buffer rather than on the
fly in scanout. This fallback needs to be completely transparent to the
user space, implying only additional latency if anything.

These 2D compositing features should be exposed to user space through a
standard kernel ABI, hopefully an existing ABI in the very near future
like the KMS atomic.

Assuming the DRM universal planes and atomic mode setting / page flip
infrastructure is in place, could the 2D compositing capabilities be
exposed through universal planes? We can assume that plane properties
are enough to describe all the compositing parameters.

Atomic updates are needed so that the complicated constraints can be
checked, and user space can try to reduce the composition complexity if
the kernel driver sees that it won't work.

Would it be feasible to generate a hundred identical non-primary planes
to be exposed to user space via DRM?

If that could be done, the kernel driver could just use the existing
kernel/user ABIs without having to invent something new, and programs
like a Wayland compositor would not need to be coded specifically for
this hardware.

What problems do you see with this plan?
Are any of those problems unfixable or simply prohibitive?

I have some concerns, which I am not sure will actually be a problem:
- Does allocating a 100 planes eat too much kernel memory?
  I mean just the bookkeeping, properties, etc.
- Would such an amount of planes make some in-kernel algorithms slow
  (particularly in DRM common code)?
- Considering how user space discovers all DRM resources, would this
  make a compositor "slow" to start?

I suppose whether these turn out to be prohibitive or not, one just has
to implement it and see. It should be usable on a slowish CPU with
unimpressive amounts of RAM, because that is where a separate 2D
compositing engine gives the most kick.

FWIW, dynamically created/destroyed planes would probably not be the
answer. The kernel driver cannot decide before-hand how many planes it
can expose. How many planes can be used depends completely on how user
space decides to use them. Therefore I believe it should expose the
maximum number always, whether there is any real use case that could
actually get them all running or not.

What if I cannot even pick a maximum number of planes, but wanted to
(as the hardware allows) let the 2D compositing scale up basically
unlimited while becoming just slower and slower?

I think at that point one would be looking at a rendering API really,
rather than a KMS API, so it's probably out of scope. Where is the line
between KMS 2D compositing with planes vs. 2D composite rendering?

Should I really be designing a driver-specific compositing API instead,
similar to what the Mesa OpenGL implementations use? Then have user
space maybe use the user space driver part via OpenWFC perhaps?
And when I mention OpenWFC, you probably notice, that I am not aware of
any standard user space API I could be implementing here. ;-)


Thanks,
pq

CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Thomas Hellstrom]

On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
>> On 08/10/2014 05:11 AM, Mario Kleiner wrote:
>>> Resent this time without HTML formatting which lkml doesn't like.
>>> Sorry.
>>>
>>> On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:
 On 08/09/2014 03:33 PM, Konrad Rzeszutek Wilk wrote:
> On August 9, 2014 1:39:39 AM EDT, Thomas
> Hellstrom  wrote:
>> Hi.
>>
> Hey Thomas!
>
>> IIRC I don't think the TTM DMA pool allocates coherent pages more
>> than
>> one page at a time, and _if that's true_ it's pretty unnecessary for
>> the
>> dma subsystem to route those allocations to CMA. Maybe Konrad could
>> shed
>> some light over this?
> It should allocate in batches and keep them in the TTM DMA pool for
> some time to be reused.
>
> The pages that it gets are in 4kb granularity though.
 Then I feel inclined to say this is a DMA subsystem bug. Single page
 allocations shouldn't get routed to CMA.

 /Thomas
>>> Yes, seems you're both right. I read through the code a bit more and
>>> indeed the TTM DMA pool allocates only one page during each
>>> dma_alloc_coherent() call, so it doesn't need CMA memory. The current
>>> allocators don't check for single page CMA allocations and therefore
>>> try to get it from the CMA area anyway, instead of skipping to the
>>> much cheaper fallback.
>>>
>>> So the callers of dma_alloc_from_contiguous() could need that little
>>> optimization of skipping it if only one page is requested. For
>>>
>>> dma_generic_alloc_coherent
>>> 
>>>
>>> andintel_alloc_coherent
>>> 
>>>  
>>> this
>>> seems easy to do. Looking at the arm arch variants, e.g.,
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://lxr.free-electrons.com/source/arch/arm/mm/dma-mapping.c%23L1194&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=QQSN6uVpEiw6RuWLAfK%2FKWBFV5HspJUfDh4Y2mUz%2FH4%3D%0A&s=4c178257eab9b5d7ca650dedba76cf27abeb49ddc7aebb9433f52b6c8bb3bbac
>>>
>>>
>>> and
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://lxr.free-electrons.com/source/arch/arm64/mm/dma-mapping.c%23L44&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=QQSN6uVpEiw6RuWLAfK%2FKWBFV5HspJUfDh4Y2mUz%2FH4%3D%0A&s=5f62f4cbe8cee1f1dd4cbba656354efe6867bcdc664cf90e9719e2f42a85de08
>>>
>>>
>>> i'm not sure if it is that easily done, as there aren't any fallbacks
>>> for such a case and the code looks to me as if that's at least
>>> somewhat intentional.
>>>
>>> As far as TTM goes, one quick one-line fix to prevent it from using
>>> the CMA at least on SWIOTLB, NOMMU and Intel IOMMU (when using the
>>> above methods) would be to clear the __GFP_WAIT
>>> 
>>> flag from the
>>> passed gfp_t flags. That would trigger the well working fallback.
>>> So, is
>>>
>>> __GFP_WAIT 
>>> 
>>>  
>>> needed
>>> for those single page allocations that go through__ttm_dma_alloc_page
>>> ?
>>>
>>>
>>> It would be nice to have such a simple, non-intrusive one-line patch
>>> that we still could get into 3.17 and then backported to older stable
>>> kernels to avoid the same desktop hangs there if CMA is enabled. It
>>> would be also nice for actual users of CMA to not use up lots of CMA
>>> space for gpu's which don't need it. I think DMA_CMA was introduced
>>> around 3.12.
>>>
>> I don't think 

How to design a DRM KMS driver exposing 2D compositing?

[Damien Lespiau]

On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> Hi,

Hi,

> there is some hardware than can do 2D compositing with an arbitrary
> number of planes. I'm not sure what the absolute maximum number of
> planes is, but for the discussion, let's say it is 100.
> 
> There are many complicated, dynamic constraints on how many, what size,
> etc. planes can be used at once. A driver would be able to check those
> before kicking the 2D compositing engine.
> 
> The 2D compositing engine in the best case (only few planes used) is
> able to composite on the fly in scanout, just like the usual overlay
> hardware blocks in CRTCs. When the composition complexity goes up, the
> driver can fall back to compositing into a buffer rather than on the
> fly in scanout. This fallback needs to be completely transparent to the
> user space, implying only additional latency if anything.

This looks like a fallback that would use GL to compose the intermediate
buffer. Any reason why that fallback can't be kicked from userspace?

-- 
Damien

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[sanjeev sharma]

Hello Roeck,

This should be replaced everywhere in driver.what do you say ?

Regards
Sanjeev Sharma


On Mon, Aug 11, 2014 at 10:01 AM, Guenter Roeck  wrote:

> spin_is_locked() always returns false in uniprocessor configurations
> and can therefore not be used with BUG_ON. Replace it with
> assert_spin_locked(), which exists for that very purpose.
>
> Signed-off-by: Guenter Roeck 
> ---
>  drivers/gpu/drm/msm/mdp/mdp_kms.c  | 2 +-
>  drivers/gpu/drm/nouveau/core/core/event.c  | 4 ++--
>  drivers/gpu/drm/nouveau/core/core/notify.c | 2 +-
>  drivers/gpu/drm/omapdrm/omap_irq.c | 2 +-
>  4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp_kms.c
> index 03455b6..92a1531 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp_kms.c
> @@ -34,7 +34,7 @@ static void update_irq(struct mdp_kms *mdp_kms)
> struct mdp_irq *irq;
> uint32_t irqmask = mdp_kms->vblank_mask;
>
> -   BUG_ON(!spin_is_locked(&list_lock));
> +   assert_spin_locked(&list_lock);
>
> list_for_each_entry(irq, &mdp_kms->irq_list, node)
> irqmask |= irq->irqmask;
> diff --git a/drivers/gpu/drm/nouveau/core/core/event.c
> b/drivers/gpu/drm/nouveau/core/core/event.c
> index 0540a48..9327117 100644
> --- a/drivers/gpu/drm/nouveau/core/core/event.c
> +++ b/drivers/gpu/drm/nouveau/core/core/event.c
> @@ -26,7 +26,7 @@
>  void
>  nvkm_event_put(struct nvkm_event *event, u32 types, int index)
>  {
> -   BUG_ON(!spin_is_locked(&event->refs_lock));
> +   assert_spin_locked(&event->refs_lock);
> while (types) {
> int type = __ffs(types); types &= ~(1 << type);
> if (--event->refs[index * event->types_nr + type] == 0) {
> @@ -39,7 +39,7 @@ nvkm_event_put(struct nvkm_event *event, u32 types, int
> index)
>  void
>  nvkm_event_get(struct nvkm_event *event, u32 types, int index)
>  {
> -   BUG_ON(!spin_is_locked(&event->refs_lock));
> +   assert_spin_locked(&event->refs_lock);
> while (types) {
> int type = __ffs(types); types &= ~(1 << type);
> if (++event->refs[index * event->types_nr + type] == 1) {
> diff --git a/drivers/gpu/drm/nouveau/core/core/notify.c
> b/drivers/gpu/drm/nouveau/core/core/notify.c
> index 76adb81..f70dbc4 100644
> --- a/drivers/gpu/drm/nouveau/core/core/notify.c
> +++ b/drivers/gpu/drm/nouveau/core/core/notify.c
> @@ -98,7 +98,7 @@ nvkm_notify_send(struct nvkm_notify *notify, void *data,
> u32 size)
> struct nvkm_event *event = notify->event;
> unsigned long flags;
>
> -   BUG_ON(!spin_is_locked(&event->list_lock));
> +   assert_spin_locked(&event->list_lock);
> BUG_ON(size != notify->size);
>
> spin_lock_irqsave(&event->refs_lock, flags);
> diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c
> b/drivers/gpu/drm/omapdrm/omap_irq.c
> index f035d2b..3eb097e 100644
> --- a/drivers/gpu/drm/omapdrm/omap_irq.c
> +++ b/drivers/gpu/drm/omapdrm/omap_irq.c
> @@ -34,7 +34,7 @@ static void omap_irq_update(struct drm_device *dev)
> struct omap_drm_irq *irq;
> uint32_t irqmask = priv->vblank_mask;
>
> -   BUG_ON(!spin_is_locked(&list_lock));
> +   assert_spin_locked(&list_lock);
>
> list_for_each_entry(irq, &priv->irq_list, node)
> irqmask |= irq->irqmask;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/78aaef92/attachment.html>

[Bug 82455] Failed to allocate virtual address for buffer

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

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

--- Comment #3 from Christian K?nig  ---
(In reply to comment #2)
>Michel D?nzer thk for your answer ,you means that the Mesa
> radeonsi drivers cannot work well on big endian hosts?

The radeonsi driver currently isn't very well tested on big endian hosts. In
theory it should work, but that doesn't mean there might be a lot of bugs.

-- 
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/20140811/47864ddf/attachment.html>

[Bug 82455] Failed to allocate virtual address for buffer

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

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

--- Comment #2 from charlie <407883775 at qq.com> ---
   Michel D?nzer thk for your answer ,you means that the Mesa radeonsi
drivers cannot work well on big endian hosts? Now ,I am read the Mesa codes and
analysis kernel code.the bo_object can create , but it not allocate virtual
space in the userspace.I am not cleaner for GEM/TTM ,and the docs is lacking. I
must analysis the code .

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

CONFIG_DMA_CMA causes ttm performance problems/hangs.

[Jerome Glisse]

On Mon, Aug 11, 2014 at 12:11:21PM +0200, Thomas Hellstrom wrote:
> On 08/10/2014 08:02 PM, Mario Kleiner wrote:
> > On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
> >> On 08/10/2014 05:11 AM, Mario Kleiner wrote:
> >>> Resent this time without HTML formatting which lkml doesn't like.
> >>> Sorry.
> >>>
> >>> On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:
>  On 08/09/2014 03:33 PM, Konrad Rzeszutek Wilk wrote:
> > On August 9, 2014 1:39:39 AM EDT, Thomas
> > Hellstrom  wrote:
> >> Hi.
> >>
> > Hey Thomas!
> >
> >> IIRC I don't think the TTM DMA pool allocates coherent pages more
> >> than
> >> one page at a time, and _if that's true_ it's pretty unnecessary for
> >> the
> >> dma subsystem to route those allocations to CMA. Maybe Konrad could
> >> shed
> >> some light over this?
> > It should allocate in batches and keep them in the TTM DMA pool for
> > some time to be reused.
> >
> > The pages that it gets are in 4kb granularity though.
>  Then I feel inclined to say this is a DMA subsystem bug. Single page
>  allocations shouldn't get routed to CMA.
> 
>  /Thomas
> >>> Yes, seems you're both right. I read through the code a bit more and
> >>> indeed the TTM DMA pool allocates only one page during each
> >>> dma_alloc_coherent() call, so it doesn't need CMA memory. The current
> >>> allocators don't check for single page CMA allocations and therefore
> >>> try to get it from the CMA area anyway, instead of skipping to the
> >>> much cheaper fallback.
> >>>
> >>> So the callers of dma_alloc_from_contiguous() could need that little
> >>> optimization of skipping it if only one page is requested. For
> >>>
> >>> dma_generic_alloc_coherent
> >>> 
> >>>
> >>> andintel_alloc_coherent
> >>> 
> >>>  
> >>> this
> >>> seems easy to do. Looking at the arm arch variants, e.g.,
> >>>
> >>> https://urldefense.proofpoint.com/v1/url?u=http://lxr.free-electrons.com/source/arch/arm/mm/dma-mapping.c%23L1194&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=QQSN6uVpEiw6RuWLAfK%2FKWBFV5HspJUfDh4Y2mUz%2FH4%3D%0A&s=4c178257eab9b5d7ca650dedba76cf27abeb49ddc7aebb9433f52b6c8bb3bbac
> >>>
> >>>
> >>> and
> >>>
> >>> https://urldefense.proofpoint.com/v1/url?u=http://lxr.free-electrons.com/source/arch/arm64/mm/dma-mapping.c%23L44&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=QQSN6uVpEiw6RuWLAfK%2FKWBFV5HspJUfDh4Y2mUz%2FH4%3D%0A&s=5f62f4cbe8cee1f1dd4cbba656354efe6867bcdc664cf90e9719e2f42a85de08
> >>>
> >>>
> >>> i'm not sure if it is that easily done, as there aren't any fallbacks
> >>> for such a case and the code looks to me as if that's at least
> >>> somewhat intentional.
> >>>
> >>> As far as TTM goes, one quick one-line fix to prevent it from using
> >>> the CMA at least on SWIOTLB, NOMMU and Intel IOMMU (when using the
> >>> above methods) would be to clear the __GFP_WAIT
> >>> 
> >>> flag from the
> >>> passed gfp_t flags. That would trigger the well working fallback.
> >>> So, is
> >>>
> >>> __GFP_WAIT 
> >>> 
> >>>  
> >>> needed
> >>> for those single page allocations that go through__ttm_dma_alloc_page
> >>> ?
> >>>
> >>>
> >>> It would be nice to have such a simple, non-intrusive one-line patch
> >>> that we still could get into 3.17 and then backported to older stable
> >>> kernels to avoid the same d

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Thierry Reding]

On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote:
> On 2014? 08? 11? 16:50, Thierry Reding wrote:
> > On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
> >> On 2014? 08? 11? 16:24, Thierry Reding wrote:
> >>> On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
> >>>> On 2014? 08? 08? 18:55, Thierry Reding wrote:
> > [...]
> >>>>> The above is actually more like this:
> >>>>>
> >>>>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
> >>>>> clear DSI_HS_CLK_CTRL;
> >>>>> else
> >>>>> set DSI_HS_CLK_CTRL;
> >>>>>
> >>>>> if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> >>>>> clear DSI_HIGH_SPEED_TRANS;
> >>>>> else
> >>>>> set DSI_HIGH_SPEED_TRANS;
> >>>>>
> >>>>> So for peripherals that don't support non-continuous clock mode, this
> >>>>> will result in the following for low-power transmissions:
> >>>>>
> >>>>> clear DSI_HS_CLK_CTRL; /* HS clock always on */
> >>>>> clear DSI_HIGH_SPEED_TRANS;
> >>>>
> >>>> Right, then how host driver should check it if peripheral doesn't
> >>>> support non-continuous clock mode? Or how the peripheral should notify
> >>>> it to host driver? It would need a new flag instead of
> >>>> MIPI_DSI_MODE_NON_CONTINUOUS.
> >>>
> >>> MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
> >>> set to signal that they support non-continuous mode. If devices don't
> >>> have that set, then the controller should always provide the HS clock.
> >>>
> >>> So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
> >>> does *not* support non-continuous mode.
> >>>
> >>
> >> Again, assume that there is a peripheral that doesn't support
> >> non-continuous clock mode but host driver want to transmit data in low
> >> power. For this, you already mentioned like below,
> >>
> >> "So for peripherals that don't support non-continuous clock mode, this
> >> will result in the following for low-power transmissions:
> >>
> >>clear DSI_HS_CLK_CTRL; /* HS clock always on */
> >>clear DSI_HIGH_SPEED_TRANS;
> >> "
> >>
> >> In this case, how should host driver check it to clear above two flags?
> >> As you know, this is required to clear two flags same as non-continuous
> >> clock mode. Don't you think that we need a new flag to identify them -
> >> non-continuous clock mode or just for low-power transmission?
> >
> > See what I wrote a little further up:
> >
> >>>>> if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
> >>>>> clear DSI_HS_CLK_CTRL;
> >>>>> else
> >>>>> set DSI_HS_CLK_CTRL;
> >>>>>
> >>>>> if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> >>>>> clear DSI_HIGH_SPEED_TRANS;
> >>>>> else
> >>>>> set DSI_HIGH_SPEED_TRANS;
> >>>>>
> >
> > MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non-
> > continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because
> > that tells the controller to turn off the HS clock between high-speed
> > transmissions.
> >
> > MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power
> > mode.
> >
> > With the above two flags we can cover four cases:
> >
> >   1) non-continuous mode with messages transmitted in low-power mode
> >   2) non-continuous mode with messages transmitted in high-speed mode
> >   3) continuous mode with messages transmitted in low-power mode
> 
> In case of 3), it would mean "set DSI_HS_CLK_CTRL" and "clear
> DSI_HIGH_SPEED_TRANS". However, msg->flags has MIPI_DSI_MSG_USE_LPM but
> dsi->mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right.
> You mean that continuous mode is set by default implicitly?

Yes, if the MIPI_DSI_MODE_NON_CONTINUOUS flag is not specified, then it
means the peripheral supports only continuous mode.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/6a21266b/attachment.sig>

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

[Christian König]

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.

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
 +
 +struct radeon_uvd_fps {
 +   uint64_ttimestamp;
 +   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];
   unsignedimg_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 = &rdev->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 = &rdev->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 = &rdev->uvd.fps_info[idx];
 +   unsigned i, valid = 0, count = 0;
 +
 +   for (i = 0; i < RADEON_UVD_FPS_EVENTS_MAX; i++) {
 +   /* We should ignore zero values */
 +   if (fps->events[i] != 0) {
 +   count += fps->events[i];
 +   valid++;
 +   }
>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #47 from arnej  ---
Created attachment 104430
  --> https://bugs.freedesktop.org/attachment.cgi?id=104430&action=edit
dmesg

I also have these problems. I attached my dmesg.

Until now (mesa 10.2.5), my system always hung completely and I had to reboot.
Now I'm using mesa git and the screen goes blank, sound continues from the
youtube video, and after about 10 seconds the screen is back and usable again.

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

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

[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.

Alex

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

[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.

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
> +
> +struct radeon_uvd_fps {
> +   uint64_ttimestamp;
> +   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];
>   unsignedimg_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 = &rdev->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 = &rdev->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)
>>>

Looking for a start point for fixing a bug

[Alex Deucher]

On Mon, Aug 11, 2014 at 12:03 AM, ?? ??  wrote:
> 2014-08-11 1:53 GMT+04:00 Niels Ole Salscheider
> :
>> On Monday 11 August 2014, 01:19:32, ?? ?? wrote:
>>> Hello again, hope you are still reading my texts...
>>>
>>> I digged through the code and narrowed down the issue I wanted to fix.
>>> It appears to be related to the `bool thermal_active` dpm struct
>>> member and this piece of code:
>>>
>>> if (rdev->asic->dpm.force_performance_level) {
>>> if (rdev->pm.dpm.thermal_active) {
>>> enum radeon_dpm_forced_level level = rdev->pm.dpm.forced_level;
>>> /* force low perf level for thermal */
>>> radeon_dpm_force_performance_level(rdev,
>>> RADEON_DPM_FORCED_LEVEL_LOW);
>>> /* save the user's level */
>>> rdev->pm.dpm.forced_level = level;
>>> } else {
>>> /* otherwise, user selected level */
>>> radeon_dpm_force_performance_level(rdev,
>>> rdev->pm.dpm.forced_level); }
>>> }
>>>
>>> I did a double check here - at boot `thermal_active` is `false` and
>>> thus, performance level is properly initiated. But at resume from
>>> suspend `thermal_active` is true and performance level is strictly
>>> bound to low profile.
>>> Besides you cannot change it via echo 1 > /sys/.../force_dpm_level,
>>> again thanks to `thermal_active` checked there.
>>>
>>> Could you explain meaning of this small boolean to me? I'd like to
>>> make a small neat patch fixing this, but I'm scared of doing it in
>>> wrong way.
>>> Sorry if I'm being too persistent.
>>
>> I think thermal_active means that the temperature got too high so that low
>> clocks have to be used.
>>
>> Just some idea, but thermal.work only gets scheduled when the high to low
>> temperature interrupt occurs. When the temperature is too high before suspend
>> (so that thermal_active is true) and it gets low during standby this 
>> interrupt
>> will not occur. thermal.work is therefore not scheduled...
>>
>> Ole
>>
>
> You were right, Ole. The driver thinks the temperature is too high.
> Thanks a lot!
> It seems the function ci_set_thermal_temperature_range is missing some lines:
>
>
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
> index 584090a..102a4bc 100644
> --- a/radeon/ci_dpm.c
> +++ b/radeon/ci_dpm.c
> @@ -869,6 +869,9 @@ static int ci_set_thermal_temperature_range(struct
> radeon_device *rdev,
> WREG32_SMC(CG_THERMAL_CTRL, tmp);
>  #endif
>
> +rdev->pm.dpm.thermal.min_temp = low_temp;
> +rdev->pm.dpm.thermal.max_temp = high_temp;
> +
> return 0;
>  }
>
>
> All other similar callbacks for different families of cards have these
> lines. I wonder if there is any specific case for not doing this...
> How do I propose it as a patch anyway?

You analysis is correct.  Thanks for tracking this down.

Alex

>
>>> Thanks,
>>> Oleg
>>>
>>> 2014-07-22 20:05 GMT+04:00 Alex Deucher :
>>> > On Tue, Jul 22, 2014 at 8:39 AM, ?? ?? 
>> wrote:
>>> >> Hello all!
>>> >>
>>> >> I have some spare time and knowledge in C to try to fix some bugs I am
>>> >> seeing on my machine.
>>> >> So I've checked out and compiled all git trees that I may need and now
>>> >> I'm
>>> >> beginning to read articles.
>>> >>
>>> >> And this is the point from where I don't know where to go. I want to fix
>>> >> particular bug #79806 [1].
>>> >> For me there are many places where this bug can hide - mesa? dri? radeon
>>> >> kernel module? and I just don't know whether should I start reading
>>> >> articles about mesa hacking or about dri architecture or about kernel
>>> >> module development.
>>> >>
>>> >> Now I think the best thing for me is to start looking through radeon
>>> >> kernel
>>> >> module code (I've got ingenious idea that power management resides there)
>>> >> and read more about its architecture. Is this right? I mean, I just want
>>> >> to
>>> >> find out, is this a right place to start looking at for this bug?
>>> >
>>> > The power management is handled in the kernel driver.  See radeon_pm.c
>>> > and the relevant *_dpm.c files depending on what asic you have.
>>> >
>>> > Alex
>>> >
>>> >> P.S. Sorry for my English in case it's not good, I'm learning it now
>>> >>
>>> >> P.P.S. And thanks for your hard work!
>>> >>
>>> >> ---
>>> >> [1] https://bugs.freedesktop.org/show_bug.cgi?id=79806
>>> >>
>>> >> ___
>>> >> dri-devel mailing list
>>> >> dri-devel at lists.freedesktop.org
>>> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>

How to design a DRM KMS driver exposing 2D compositing?

[Eric Anholt]

Daniel Vetter  writes:

> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
>> Hi,
>> 
>> there is some hardware than can do 2D compositing with an arbitrary
>> number of planes. I'm not sure what the absolute maximum number of
>> planes is, but for the discussion, let's say it is 100.
>> 
>> There are many complicated, dynamic constraints on how many, what size,
>> etc. planes can be used at once. A driver would be able to check those
>> before kicking the 2D compositing engine.
>> 
>> The 2D compositing engine in the best case (only few planes used) is
>> able to composite on the fly in scanout, just like the usual overlay
>> hardware blocks in CRTCs. When the composition complexity goes up, the
>> driver can fall back to compositing into a buffer rather than on the
>> fly in scanout. This fallback needs to be completely transparent to the
>> user space, implying only additional latency if anything.
>> 
>> These 2D compositing features should be exposed to user space through a
>> standard kernel ABI, hopefully an existing ABI in the very near future
>> like the KMS atomic.
>
> I presume we're talking about the video core from raspi? Or at least
> something similar?

Pekka wasn't sure if things were confidential here, but I can say it:
Yeah, it's the RPi.

While I haven't written code using the compositor interface (I just did
enough to shim in a single plane for bringup, and I'm hoping Pekka and
company can handle the rest for me :) ), my understanding is that the
way you make use of it is that you've got your previous frame loaded up
in the HVS (the plane compositor hardware), then when you're asked to
put up a new frame that's going to be too hard, you take some
complicated chunk of your scene and ask the HVS to use any spare
bandwidth it has while it's still scanning out the previous frame in
order to composite that piece of new scene into memory.  Then, when it's
done with the offline composite, you ask the HVS to do the next scanout
frame using the original scene with the pre-composited temporary buffer.

I'm pretty comfortable with the idea of having some large number of
planes preallocated, and deciding that "nobody could possibly need more
than 16" (or whatever).

My initial reaction to "we should just punt when we run out of bandwidth
and have a special driver interface for offline composite" was "that's
awful, when the kernel could just get the job done immediately, and
easily, and it would know exactly what it needed to composite to get
things to fit (unlike userspace)".  I'm trying to come up with what
benefit there would be to having a separate interface for offline
composite.  I've got 3 things:

- Avoids having a potentially long, interruptible wait in the modeset
  path while the offline composite happens.  But I think we have other
  interruptible waits in that path alreaady.

- Userspace could potentially do something else besides use the HVS to
  get the fallback done.  Video would have to use the HVS, to get the
  same scaling filters applied as the previous frame where things *did*
  fit, but I guess you could composite some 1:1 RGBA overlays in GL,
  which would have more BW available to it than what you're borrowing
  from the previous frame's HVS capacity.

- Userspace could potentially use the offline composite interface for
  things besides just the running-out-of-bandwidth case.  Like, it was
  doing a nicely-filtered downscale of an overlaid video, then the user
  hit pause and walked away: you could have a timeout that noticed that
  the complicated scene hadn't changed in a while, and you'd drop from
  overlays to a HVS-composited single plane to reduce power.

The third one is the one I've actually found kind of compelling, and
might be switching me from wanting no userspace visibility into the
fallback.  But I don't have a good feel for how much complexity there is
to our descriptions of planes, and how much poorly-tested interface we'd
be adding to support this usecase.

(Because, honestly, I don't expect the fallbacks to be hit much -- my
understanding of the bandwidth equation is that you're mostly counting
the number of pixels that have to be read, and clipped-out pixels
because somebody's overlaid on top of you don't count unless they're in
the same burst read.  So unless people are going nuts with blending in
overlays, or downscaled video, it's probably not a problem, and
something that gets your pixels on the screen at all is sufficient)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/9e912647/attachment.sig>

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Andrzej Hajda]

On 08/11/2014 09:44 AM, Andrzej Hajda wrote:
> On 08/11/2014 09:09 AM, Inki Dae wrote:
>> On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
>>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
 On 08/08/2014 09:37 AM, Inki Dae wrote:
> On 2014? 08? 08? 16:03, Thierry Reding wrote:
>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 22:55, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 22:17, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 20:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
> On 2014? 08? 07? 18:09, Thierry Reding wrote:
>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>>> On 2014? 08? 07? 15:58, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
> 2014-08-06 16:43 GMT+09:00 Thierry Reding  gmail.com>:
>> [...]
>> As far as I can tell non-continuous mode simply means that 
>> the host can
>> turn off the HS clock after a high-speed transmission. I 
>> think Andrzej
>> mentioned this already in another subthread, but this is an 
>> optional
>> mode that peripherals can support if they have extra 
>> circuitry that
>> provides an internal clock. Peripherals that don't have such 
>> circuitry
>> may rely on the HS clock to perform in between transmissions 
>> and
>> therefore require the HS clock to be always on (continuous 
>> mode). That's
>> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it 
>> advertises that the
>> peripheral supports non-continuous mode and therefore the 
>> host can turn
>> the HS clock off after high-speed transmissions.
> What I don't make sure is this sentence. With
> MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
> operations.
> One is,
> 1. host controller will generates signals if a bit of a 
> register
> related to non-contiguous clock mode is set or unset.
> 2. And then video data is transmitted to panel in HS mode.
> 3. And then D-PHY detects LP-11 signal (positive and negative 
> lane all
> are high).
> 4. And then D-PHY disables HS clock of host controller.
> 5. At this time, operation mode of host controller becomes 
> LPM.
>
> Other is,
> 1. host controller will generates signals if a bit of a 
> register
> related to non-contiguous clock mode is set or unset.
> 2. And then D-PHY detects LP-11 signal (positive and negative 
> lane all
> are high).
> 3. And then video data is transmitted to panel in LPM.
> 4. At this time, operation mode of host controller becomes 
> LPM.
>
> It seems that you says latter case.
 No. High speed clock and low power mode are orthogonal. 
 Non-continuous
 mode simply means that the clock lane enters LP-11 between HS
 transmissions (see 5.6 "Clock Management" of the DSI 
 specification).

>>> It seems that clock lane enters LP-11 regardless of HS clock 
>>> enabled if
>>> non-continous mode is used. Right?
>> No, I think as long as HS clock is enabled the clock lane won't 
>> enter
>> LP-11. Non-continuous mode means that the controller can disable 
>> the HS
>> clock between HS transmissions. So in non-continuous mode the 
>> clock lane
>> can enter LP-11 because the controller disables the HS clock.
> It makes me a little bit confusing. You said "if HS clock is 
> enabled,
> the the clock lane won't enter LP-11" But you said again "the 
> clock lane
> can enter LP-11 because the controller disables the HS clock" 
> What is
> the meaning?
 It means that if the HS clock is enabled, then the clock lane is 
 not in
 LP-11. When the HS clock stops, then the clock lane enters LP-11.

>> In continuous mode, then the clock will never be disabled, hence 
>> the
>> clock 

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Thierry Reding]

On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
> On 2014? 08? 11? 16:24, Thierry Reding wrote:
> > On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
> >> On 2014? 08? 08? 18:55, Thierry Reding wrote:
[...]
> >>> The above is actually more like this:
> >>>
> >>>   if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
> >>>   clear DSI_HS_CLK_CTRL;
> >>>   else
> >>>   set DSI_HS_CLK_CTRL;
> >>>
> >>>   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> >>>   clear DSI_HIGH_SPEED_TRANS;
> >>>   else
> >>>   set DSI_HIGH_SPEED_TRANS;
> >>>
> >>> So for peripherals that don't support non-continuous clock mode, this
> >>> will result in the following for low-power transmissions:
> >>>
> >>>   clear DSI_HS_CLK_CTRL; /* HS clock always on */
> >>>   clear DSI_HIGH_SPEED_TRANS;
> >>
> >> Right, then how host driver should check it if peripheral doesn't
> >> support non-continuous clock mode? Or how the peripheral should notify
> >> it to host driver? It would need a new flag instead of
> >> MIPI_DSI_MODE_NON_CONTINUOUS.
> >
> > MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
> > set to signal that they support non-continuous mode. If devices don't
> > have that set, then the controller should always provide the HS clock.
> >
> > So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
> > does *not* support non-continuous mode.
> >
> 
> Again, assume that there is a peripheral that doesn't support
> non-continuous clock mode but host driver want to transmit data in low
> power. For this, you already mentioned like below,
> 
> "So for peripherals that don't support non-continuous clock mode, this
> will result in the following for low-power transmissions:
> 
>   clear DSI_HS_CLK_CTRL; /* HS clock always on */
>   clear DSI_HIGH_SPEED_TRANS;
> "
> 
> In this case, how should host driver check it to clear above two flags?
> As you know, this is required to clear two flags same as non-continuous
> clock mode. Don't you think that we need a new flag to identify them -
> non-continuous clock mode or just for low-power transmission?

See what I wrote a little further up:

> >>>   if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
> >>>   clear DSI_HS_CLK_CTRL;
> >>>   else
> >>>   set DSI_HS_CLK_CTRL;
> >>>
> >>>   if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> >>>   clear DSI_HIGH_SPEED_TRANS;
> >>>   else
> >>>   set DSI_HIGH_SPEED_TRANS;
> >>>

MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non-
continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because
that tells the controller to turn off the HS clock between high-speed
transmissions.

MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power
mode.

With the above two flags we can cover four cases:

  1) non-continuous mode with messages transmitted in low-power mode
  2) non-continuous mode with messages transmitted in high-speed mode
  3) continuous mode with messages transmitted in low-power mode
  4) continuous mode with messages transmitted in high-speed mode

What other cases do you think we need to support?

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/45e0812a/attachment.sig>

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Andrzej Hajda]

On 08/11/2014 09:09 AM, Inki Dae wrote:
> On 2014? 08? 08? 18:40, Andrzej Hajda wrote:
>> On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
>>> On 08/08/2014 09:37 AM, Inki Dae wrote:
 On 2014? 08? 08? 16:03, Thierry Reding wrote:
> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 22:55, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 22:17, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 20:09, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
 On 2014? 08? 07? 18:09, Thierry Reding wrote:
> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
>> On 2014? 08? 07? 15:58, Thierry Reding wrote:
>>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
 2014-08-06 16:43 GMT+09:00 Thierry Reding >>> gmail.com>:
> [...]
> As far as I can tell non-continuous mode simply means that 
> the host can
> turn off the HS clock after a high-speed transmission. I 
> think Andrzej
> mentioned this already in another subthread, but this is an 
> optional
> mode that peripherals can support if they have extra 
> circuitry that
> provides an internal clock. Peripherals that don't have such 
> circuitry
> may rely on the HS clock to perform in between transmissions 
> and
> therefore require the HS clock to be always on (continuous 
> mode). That's
> what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
> that the
> peripheral supports non-continuous mode and therefore the 
> host can turn
> the HS clock off after high-speed transmissions.
 What I don't make sure is this sentence. With
 MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
 operations.
 One is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then video data is transmitted to panel in HS mode.
 3. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 4. And then D-PHY disables HS clock of host controller.
 5. At this time, operation mode of host controller becomes LPM.

 Other is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 3. And then video data is transmitted to panel in LPM.
 4. At this time, operation mode of host controller becomes LPM.

 It seems that you says latter case.
>>> No. High speed clock and low power mode are orthogonal. 
>>> Non-continuous
>>> mode simply means that the clock lane enters LP-11 between HS
>>> transmissions (see 5.6 "Clock Management" of the DSI 
>>> specification).
>>>
>> It seems that clock lane enters LP-11 regardless of HS clock 
>> enabled if
>> non-continous mode is used. Right?
> No, I think as long as HS clock is enabled the clock lane won't 
> enter
> LP-11. Non-continuous mode means that the controller can disable 
> the HS
> clock between HS transmissions. So in non-continuous mode the 
> clock lane
> can enter LP-11 because the controller disables the HS clock.
 It makes me a little bit confusing. You said "if HS clock is 
 enabled,
 the the clock lane won't enter LP-11" But you said again "the 
 clock lane
 can enter LP-11 because the controller disables the HS clock" What 
 is
 the meaning?
>>> It means that if the HS clock is enabled, then the clock lane is 
>>> not in
>>> LP-11. When the HS clock stops, then the clock lane enters LP-11.
>>>
> In continuous mode, then the clock will never be disabled, hence 
> the
> clock lane will never enter LP-11.
>
>> And also it seems that non-continous mode is different from LPM 
>> at all
>> because with non-

[PATCH] drm/panel/simple: add optronics B101XTN01.0 (v3)

[Thierry Reding]

On Sun, Aug 10, 2014 at 10:13:45AM -0400, Rob Clark wrote:
> LVDS panel, make/model described as:
> 
> AU Optronics Corporation - B101XTN01.0 (H/W:0A)
> 
> See:
> http://www.encore-electronic.com/media/B101XTN01.0.pdf
> 
> Tested with panel attached to an Inforce IFC6410 board.
> 
> Signed-off-by: Rob Clark 
> ---
> v1: original
> v2: review comments from Thierry Reding
> v3: rebase on drm-next (adds bpc)
> 
>  .../devicetree/bindings/panel/auo,b101xtn01.txt|  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 27 
> ++
>  2 files changed, 34 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/panel/auo,b101xtn01.txt

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/a5028c73/attachment.sig>

[Bug 82455] Failed to allocate virtual address for buffer

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

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

--- Comment #1 from Michel D?nzer  ---
> radeon :01:00.0: bo f801f3ee2c00 va 0x conflict with (bo 
> f801f3ee3000 0x0080 0x00802000)

Looks like the Mesa radeon winsys is not assigning GPU virtual memory addresses
correctly (0x is not a valid virtual address).

You might have better luck with that with current Mesa Git master, but note
that the Mesa radeonsi driver needs a lot of work before it has any chance of
working correctly on big endian hosts.

-- 
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/20140811/58b47302/attachment.html>

How to design a DRM KMS driver exposing 2D compositing?

[Rob Clark]

On Mon, Aug 11, 2014 at 8:06 AM, Daniel Vetter  wrote:
> On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
>> Hi,
>>
>> there is some hardware than can do 2D compositing with an arbitrary
>> number of planes. I'm not sure what the absolute maximum number of
>> planes is, but for the discussion, let's say it is 100.
>>
>> There are many complicated, dynamic constraints on how many, what size,
>> etc. planes can be used at once. A driver would be able to check those
>> before kicking the 2D compositing engine.
>>
>> The 2D compositing engine in the best case (only few planes used) is
>> able to composite on the fly in scanout, just like the usual overlay
>> hardware blocks in CRTCs. When the composition complexity goes up, the
>> driver can fall back to compositing into a buffer rather than on the
>> fly in scanout. This fallback needs to be completely transparent to the
>> user space, implying only additional latency if anything.
>>
>> These 2D compositing features should be exposed to user space through a
>> standard kernel ABI, hopefully an existing ABI in the very near future
>> like the KMS atomic.
>
> I presume we're talking about the video core from raspi? Or at least
> something similar?
>
>> Assuming the DRM universal planes and atomic mode setting / page flip
>> infrastructure is in place, could the 2D compositing capabilities be
>> exposed through universal planes? We can assume that plane properties
>> are enough to describe all the compositing parameters.
>>
>> Atomic updates are needed so that the complicated constraints can be
>> checked, and user space can try to reduce the composition complexity if
>> the kernel driver sees that it won't work.
>>
>> Would it be feasible to generate a hundred identical non-primary planes
>> to be exposed to user space via DRM?
>>
>> If that could be done, the kernel driver could just use the existing
>> kernel/user ABIs without having to invent something new, and programs
>> like a Wayland compositor would not need to be coded specifically for
>> this hardware.
>>
>> What problems do you see with this plan?
>> Are any of those problems unfixable or simply prohibitive?
>>
>> I have some concerns, which I am not sure will actually be a problem:
>> - Does allocating a 100 planes eat too much kernel memory?
>>   I mean just the bookkeeping, properties, etc.
>> - Would such an amount of planes make some in-kernel algorithms slow
>>   (particularly in DRM common code)?
>> - Considering how user space discovers all DRM resources, would this
>>   make a compositor "slow" to start?
>
> I don't see any problem with that. We have a few plane-loops, but iirc
> those can be easily fixed to use indices and similar stuff. The atomic
> ioctl itself should scale nicely.
>
>> I suppose whether these turn out to be prohibitive or not, one just has
>> to implement it and see. It should be usable on a slowish CPU with
>> unimpressive amounts of RAM, because that is where a separate 2D
>> compositing engine gives the most kick.
>>
>> FWIW, dynamically created/destroyed planes would probably not be the
>> answer. The kernel driver cannot decide before-hand how many planes it
>> can expose. How many planes can be used depends completely on how user
>> space decides to use them. Therefore I believe it should expose the
>> maximum number always, whether there is any real use case that could
>> actually get them all running or not.
>
> Yeah dynamic planes doesn't sound like a nice solution, least because
> you'll get to audit piles of code. Currently really only framebuffers (and
> to some extent connectors) can come and go freely in kms-land.
>
>> What if I cannot even pick a maximum number of planes, but wanted to
>> (as the hardware allows) let the 2D compositing scale up basically
>> unlimited while becoming just slower and slower?
>>
>> I think at that point one would be looking at a rendering API really,
>> rather than a KMS API, so it's probably out of scope. Where is the line
>> between KMS 2D compositing with planes vs. 2D composite rendering?
>
> I think kms should still be real-time compositing - if you have to
> internally render to a buffer and then scan that one out due to lack of
> memory bandwidth or so that very much sounds like a rendering api. Ofc
> stuff like writeback buffers blurry that a bit. But hw writeback is still
> real-time.

not really sure how much of this is exposed to the cpu side, vs hidden
on coproc..

but I tend to think it would be nice for compositors (userspace) to
know explicitly what is going on..  ie. if some layers are blended via
intermediate buffer, couldn't that intermediate buffer be potentially
re-used on next frame if not damaged?


>> Should I really be designing a driver-specific compositing API instead,
>> similar to what the Mesa OpenGL implementations use? Then have user
>> space maybe use the user space driver part via OpenWFC perhaps?
>> And when I mention OpenWFC, you probably notice, that I am not aware of
>> any s

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Thierry Reding]

gt;>>>>>>>>>> before the host driver transmits command data?
> >>>>>>>>>>>
> >>>>>>>>>>> No. If the peripheral doesn't support non-continuous mode, then 
> >>>>>>>>>>> the HS
> >>>>>>>>>>> clock must never be turned off. On the other hand, if the 
> >>>>>>>>>>> peripheral
> >>>>>>>>>>> supports non-continuous mode, then the DSI host should 
> >>>>>>>>>>> automatically
> >>>>>>>>>>> disable the HS clock between high-speed transmissions. That means 
> >>>>>>>>>>> if a
> >>>>>>>>>>> packet is transmitted in low power mode the DSI host will not be
> >>>>>>>>>>> transmitting in high-speed mode and therefore disable the HS 
> >>>>>>>>>>> clock.
> >>>>>>>>>>
> >>>>>>>>>> What is LPM you think? I thought LPM is LP-11 and HS clock 
> >>>>>>>>>> disabled. So
> >>>>>>>>>> for LPM transfer, lanes should be LP-11 state and also HS clock of 
> >>>>>>>>>> the
> >>>>>>>>>> host controller should be disabled.
> >>>>>>>>>
> >>>>>>>>> No. I don't think any transmissions can happen when all lanes are in
> >>>>>>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a 
> >>>>>>>>> packet
> >>>>>>>>> should be transmitted in low power mode (see LP Transmission in 2.1
> >>>>>>>>> "Definitions" of the MIPI DSI specification).
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Hm.. I see. I meant,
> >>>>>>>>
> >>>>>>>> if (flags & MIPI_DSI_MSG_USE_LPM)
> >>>>>>>>disable HS clock <- required.
> >>>>>>>>
> >>>>>>>> transmit command data <- in LPM.
> >>>>>>>
> >>>>>>> No. Disabling the HS clock is not required for LPM mode. In fact if 
> >>>>>>> the
> >>>>>>> peripheral specifies that it doesn't support non-continuous mode then
> >>>>>>> the HS clock must *never* be disabled as long as the peripheral is in
> >>>>>>> use.
> >>>>>>>
> >>>>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated 
> >>>>>>> and
> >>>>>>> need to be considered separately.
> >>>>>>
> >>>>>> I mentioned already LPM and NON_CONTINUOUS are unrelated.
> >>>>>>
> >>>>>> It seems that you say the only way to transfer command data in LPM is
> >>>>>> non-continuous clock mode.
> >>>>>
> >>>>> No, that's not what I'm saying.
> >>>>>
> >>>>>> However, you said and also the spec says, "Non-continuous mode simply
> >>>>>> means that the clock lane enters LP-11 between HS transmissions".
> >>>>>> Doesn't *between HS transmissions" mean the command data is transmitted
> >>>>>> in HS, *not in LPM*, and clock lane enters LP-11 between them?
> >>>>>
> >>>>> Not necessarily. You can transmit command packets in high-speed mode,
> >>>>> but you don't have to. If you transmit packets in low power mode, then
> >>>>
> >>>> That would may why we are mentioning same comments repeatedly.
> >>>>
> >>>> In my case, host driver waits for the lane stop state (LP-11), and then
> >>>> disables HS clock to transmit command data in LPM. Of course, I'm not
> >>>> sure that yet it's correct way.
> >>>
> >>> That's confusing. How can the lane go to LP-11 when the clock is still
> >>> running?
> >>
> >> Actually, we are doing so. If the clock is still running then dsi driver
> >> will wait for stop state of the clock and data lanes. Know that this is
> >> valid only when initial time - just one time since power up.
> >>
> >>/* Check clock and data lane state are stop state */
> >>timeout = 100;
> >>do {
> >>if (timeout-- == 0) {
> >>dev_err(dsi->dev, "waiting for bus lanes timed out\n");
> >>return -EFAULT;
> >>}
> >>
> >>reg = readl(dsi->reg_base + DSIM_STATUS_REG);
> >>if ((reg & DSIM_STOP_STATE_DAT(lanes_mask))
> >>!= DSIM_STOP_STATE_DAT(lanes_mask))
> >>continue;
> >>} while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK)));
> >>
> >>>
> >>>> In Tegra, What to do for it?
> >>>
> >>> There are two bits in two separate registers for this:
> >>>
> >>>   DSI_HOST_CONTROL:
> >>> bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of
> >>>  packets
> >>>   - 0 = LOW: low speed
> >>>   - 1 = HIGH: high speed
> >>>
> >>>   DSI_CONTROL:
> >>> bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane
> >>>   - 0 = CONTINUOUS: HS clock is on all the time
> >>>   - 1 = TX_ONLY: HS clock is only active during HS
> >>>  transmissions
> >>>
> >>> So if the peripheral supports non-continuous mode of operation we set
> >>> the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock
> >>> remains on all the time.
> >>>
> >>> When a packet is to be transmitted in high speed mode, we set the
> >>> DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is
> >>> cleared.
> >>
> >> That is exactly what I want. In your case, if you want to transmit
> >> command data in Low Power Mode in case of supporting non-continuous
> >> clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you
> >> would clear DSI_HIGH_SPEED_TRANS (LOW).
> >>
> >> So I guess,
> >>
> >> if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) {
> >> disable DSI_HIGH_SPEED_TRANS;   <- LOW
> >> enable DSI_HS_CLK_CTRL; <- TX_ONLY
> >> }
> >>
> >> transmit command data <- in LPM.
> >>
> >> However, what if the peripheral doesn't support non-continuous but want
> >> to transmit command data in LPM? Is that  impossible?
> > 
> > The above is actually more like this:
> > 
> > if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
> > clear DSI_HS_CLK_CTRL;
> > else
> > set DSI_HS_CLK_CTRL;
> > 
> > if (msg->flags & MIPI_DSI_MSG_USE_LPM)
> > clear DSI_HIGH_SPEED_TRANS;
> > else
> > set DSI_HIGH_SPEED_TRANS;
> > 
> > So for peripherals that don't support non-continuous clock mode, this
> > will result in the following for low-power transmissions:
> > 
> > clear DSI_HS_CLK_CTRL; /* HS clock always on */
> > clear DSI_HIGH_SPEED_TRANS;
> 
> Right, then how host driver should check it if peripheral doesn't
> support non-continuous clock mode? Or how the peripheral should notify
> it to host driver? It would need a new flag instead of
> MIPI_DSI_MODE_NON_CONTINUOUS.

MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
set to signal that they support non-continuous mode. If devices don't
have that set, then the controller should always provide the HS clock.

So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
does *not* support non-continuous mode.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140811/36706a79/attachment-0001.sig>

[Bug 82455] Failed to allocate virtual address for buffer

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

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

charlie <407883775 at qq.com> changed:

   What|Removed |Added

 QA Contact||407883775 at qq.com

-- 
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/20140811/78305d44/attachment.html>

[Bug 82455] New: Failed to allocate virtual address for buffer

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

0
[  887.564672] radeon :01:00.0: soffset:0x0010, eoffset: 0x0020 
[  887.564696] radeon :01:00.0: tmp->soffset:0x, tmp->eoffset:
0x, size:0x0010
[  985.395298] radeon :01:00.0: soffset:0x0010, eoffset: 0x0020 
[  985.395332] radeon :01:00.0: tmp->soffset:0x, tmp->eoffset:
0x, size:0x0010
[  987.861353] radeon :01:00.0: soffset:0x0010, eoffset: 0x0020 
[  987.861387] radeon :01:00.0: tmp->soffset:0x, tmp->eoffset:
0x, size:0x0010
[  988.175840] radeon :01:00.0: soffset:0x0010, eoffset: 0x0020 
[  988.175873] radeon :01:00.0: tmp->soffset:0x, tmp->eoffset:
0x, size:0x0010
[  988.176054] radeon :01:00.0: soffset:0x0010, eoffset: 0x0020 
[  988.176078] radeon :01:00.0: tmp->soffset:0x, tmp->eoffset:
0x, size:0x0010

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

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

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

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

--- Comment #23 from smoki  ---
(In reply to comment #22)
>  And he said chips handle these cases, no driver need to somhow check for
> those. I gueesed that maybe that "Stencil op fail or zfail is not KEEP" is
> culprit but who knows :)
> 
>  http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Depth_in-
> depth.pdf#6
>  http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Depth_in-
> depth.pdf#10

 I mean that one for an artifacts we have in some apps :)

 "Unfortunately the conventional method can get artifacts if the shadow volume
intersects the near clipping plane (if front plane capping is not used, that
is), which has made the Z-fail method the algorithm of choice for most deve
lopers."

-- 
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/20140811/5f661ce7/attachment.html>

Looking for a start point for fixing a bug

[Niels Ole Salscheider]

On Monday 11 August 2014, 08:03:57, ?? ?? wrote:
> 2014-08-11 1:53 GMT+04:00 Niels Ole Salscheider
> 
> :
> > On Monday 11 August 2014, 01:19:32, ?? ?? wrote:
> >> Hello again, hope you are still reading my texts...
> >> 
> >> I digged through the code and narrowed down the issue I wanted to fix.
> >> It appears to be related to the `bool thermal_active` dpm struct
> >> member and this piece of code:
> >> 
> >> if (rdev->asic->dpm.force_performance_level) {
> >> 
> >> if (rdev->pm.dpm.thermal_active) {
> >> 
> >> enum radeon_dpm_forced_level level =
> >> rdev->pm.dpm.forced_level;
> >> /* force low perf level for thermal */
> >> radeon_dpm_force_performance_level(rdev,
> >> 
> >> RADEON_DPM_FORCED_LEVEL_LOW);
> >> 
> >> /* save the user's level */
> >> rdev->pm.dpm.forced_level = level;
> >> 
> >> } else {
> >> 
> >> /* otherwise, user selected level */
> >> radeon_dpm_force_performance_level(rdev,
> >> 
> >> rdev->pm.dpm.forced_level); }
> >> 
> >> }
> >> 
> >> I did a double check here - at boot `thermal_active` is `false` and
> >> thus, performance level is properly initiated. But at resume from
> >> suspend `thermal_active` is true and performance level is strictly
> >> bound to low profile.
> >> Besides you cannot change it via echo 1 > /sys/.../force_dpm_level,
> >> again thanks to `thermal_active` checked there.
> >> 
> >> Could you explain meaning of this small boolean to me? I'd like to
> >> make a small neat patch fixing this, but I'm scared of doing it in
> >> wrong way.
> >> Sorry if I'm being too persistent.
> > 
> > I think thermal_active means that the temperature got too high so that low
> > clocks have to be used.
> > 
> > Just some idea, but thermal.work only gets scheduled when the high to low
> > temperature interrupt occurs. When the temperature is too high before
> > suspend (so that thermal_active is true) and it gets low during standby
> > this interrupt will not occur. thermal.work is therefore not scheduled...
> > 
> > Ole
> 
> You were right, Ole. The driver thinks the temperature is too high.
> Thanks a lot!
> It seems the function ci_set_thermal_temperature_range is missing some
> lines:
> 
> 
> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
> b/drivers/gpu/drm/radeon/ci_dpm.c index 584090a..102a4bc 100644
> --- a/radeon/ci_dpm.c
> +++ b/radeon/ci_dpm.c
> @@ -869,6 +869,9 @@ static int ci_set_thermal_temperature_range(struct
> radeon_device *rdev,
> WREG32_SMC(CG_THERMAL_CTRL, tmp);
>  #endif
> 
> +rdev->pm.dpm.thermal.min_temp = low_temp;
> +rdev->pm.dpm.thermal.max_temp = high_temp;
> +
> return 0;
>  }
> 
> 
> All other similar callbacks for different families of cards have these
> lines. I wonder if there is any specific case for not doing this...

This seems to be wrong indeed. I wonder why it happens after a suspend - 
resume cycle, though. Does the hardware generate a corresponding interrupt 
after resume?

There is however still an XXX comment in that function... Maybe Alex can 
comment on that.

> How do I propose it as a patch anyway?

Fix it in your local git checkout, commit it (don't forget to pass -s to get 
your signed-of-by line) and use git format-patch / git send-email to send it 
to this list...

> >> Thanks,
> >> Oleg
> >> 
> >> 2014-07-22 20:05 GMT+04:00 Alex Deucher :
> >> > On Tue, Jul 22, 2014 at 8:39 AM, ?? ?? 
> > 
> > wrote:
> >> >> Hello all!
> >> >> 
> >> >> I have some spare time and knowledge in C to try to fix some bugs I am
> >> >> seeing on my machine.
> >> >> So I've checked out and compiled all git trees that I may need and now
> >> >> I'm
> >> >> beginning to read articles.
> >> >> 
> >> >> And this is the point from where I don't know where to go. I want to
> >> >> fix
> >> >> particular bug #79806 [1].
> >> >> For me there are many places where this bug can hide - mesa? dri?
> >> >> radeon
> >> >> kernel module? and I just don't know whether should I start reading
> >> >> articles about mesa hacking or about dri architecture or about kernel
> >> >> module development.
> >> >> 
> >> >> Now I think the best thing for me is to start looking through radeon
> >> >> kernel
> >> >> module code (I've got ingenious idea that power management resides
> >> >> there)
> >> >> and read more about its architecture. Is this right? I mean, I just
> >> >> want
> >> >> to
> >> >> find out, is this a right place to start looking at for this bug?
> >> > 
> >> > The power management is handled in the kernel driver.  See radeon_pm.c
> >> > and the relevant *_dpm.c files depending on what asic you have.
> >> > 
> >> > Alex
> >> > 
> >> >> P.S. Sorry for my English in case it's not good, I'm learning it now
> >> >> 
> >> >> P.P.S. And thanks for your hard work!
> >> >> 
> >> >> ---
> >> >> [1] https://bugs.freedesktop.org/show_bug.cgi?id=7980

[Bug 50135] Unigine Heaven black stripes and weird shaders

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

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

--- Comment #15 from Micael Dias  ---
(In reply to comment #14)
> Is this still an issue with current Mesa?

I no longer have access to the hardware, so I cannot confirm.

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

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

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

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

--- Comment #22 from smoki  ---

 And he said chips handle these cases, no driver need to somhow check for
those. I gueesed that maybe that "Stencil op fail or zfail is not KEEP" is
culprit but who knows :)


http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Depth_in-depth.pdf#6

http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Depth_in-depth.pdf#10

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

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

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

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

--- Comment #21 from smoki  ---
(In reply to comment #20)
> (In reply to comment #18)
> >  So if someone succesfully fix that currently in various ways broken shadows
> > setup in r600/radeonsi code, he will fix hyperz artifacts too :).
> 
> It's not that simple unfortunately. At least in Sanctuary, the shadows work
> perfectly now without HyperZ but are still broken with it.

 I know i mentionied that here:
https://bugs.freedesktop.org/show_bug.cgi?id=79035#c6

 Anyway besides more artifacts of course (i mentioned yesterday on irc to
marek) that if i just disable stencil in si_state.c, there is no lockups in
these traces/apps when hyperz is enabled S_028800_STENCIL_ENABLE(0)

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

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Christian K?nig  ---
Going to take a look as soon as I have time.

-- 
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/20140811/8b4da7dd/attachment.html>

[Bug 82428] [radeonsi,R9 270X] System lockup when using mplayer/mpv with VDPAU

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

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

--- Comment #2 from smoki  ---

 Same for me with current mesa git on Athlon 5350. xserver 1.16, mpv 0.4.3,
libav 10.3, vdpau-0.7 and kernel 3.16.0.

-- 
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/20140811/03f2e3af/attachment.html>

Looking for a start point for fixing a bug

[Адонай Элохим]

2014-08-11 1:53 GMT+04:00 Niels Ole Salscheider
:
> On Monday 11 August 2014, 01:19:32, ?? ?? wrote:
>> Hello again, hope you are still reading my texts...
>>
>> I digged through the code and narrowed down the issue I wanted to fix.
>> It appears to be related to the `bool thermal_active` dpm struct
>> member and this piece of code:
>>
>> if (rdev->asic->dpm.force_performance_level) {
>> if (rdev->pm.dpm.thermal_active) {
>> enum radeon_dpm_forced_level level = rdev->pm.dpm.forced_level;
>> /* force low perf level for thermal */
>> radeon_dpm_force_performance_level(rdev,
>> RADEON_DPM_FORCED_LEVEL_LOW);
>> /* save the user's level */
>> rdev->pm.dpm.forced_level = level;
>> } else {
>> /* otherwise, user selected level */
>> radeon_dpm_force_performance_level(rdev,
>> rdev->pm.dpm.forced_level); }
>> }
>>
>> I did a double check here - at boot `thermal_active` is `false` and
>> thus, performance level is properly initiated. But at resume from
>> suspend `thermal_active` is true and performance level is strictly
>> bound to low profile.
>> Besides you cannot change it via echo 1 > /sys/.../force_dpm_level,
>> again thanks to `thermal_active` checked there.
>>
>> Could you explain meaning of this small boolean to me? I'd like to
>> make a small neat patch fixing this, but I'm scared of doing it in
>> wrong way.
>> Sorry if I'm being too persistent.
>
> I think thermal_active means that the temperature got too high so that low
> clocks have to be used.
>
> Just some idea, but thermal.work only gets scheduled when the high to low
> temperature interrupt occurs. When the temperature is too high before suspend
> (so that thermal_active is true) and it gets low during standby this interrupt
> will not occur. thermal.work is therefore not scheduled...
>
> Ole
>

You were right, Ole. The driver thinks the temperature is too high.
Thanks a lot!
It seems the function ci_set_thermal_temperature_range is missing some lines:


diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 584090a..102a4bc 100644
--- a/radeon/ci_dpm.c
+++ b/radeon/ci_dpm.c
@@ -869,6 +869,9 @@ static int ci_set_thermal_temperature_range(struct
radeon_device *rdev,
WREG32_SMC(CG_THERMAL_CTRL, tmp);
 #endif

+rdev->pm.dpm.thermal.min_temp = low_temp;
+rdev->pm.dpm.thermal.max_temp = high_temp;
+
return 0;
 }


All other similar callbacks for different families of cards have these
lines. I wonder if there is any specific case for not doing this...
How do I propose it as a patch anyway?

>> Thanks,
>> Oleg
>>
>> 2014-07-22 20:05 GMT+04:00 Alex Deucher :
>> > On Tue, Jul 22, 2014 at 8:39 AM, ?? ?? 
> wrote:
>> >> Hello all!
>> >>
>> >> I have some spare time and knowledge in C to try to fix some bugs I am
>> >> seeing on my machine.
>> >> So I've checked out and compiled all git trees that I may need and now
>> >> I'm
>> >> beginning to read articles.
>> >>
>> >> And this is the point from where I don't know where to go. I want to fix
>> >> particular bug #79806 [1].
>> >> For me there are many places where this bug can hide - mesa? dri? radeon
>> >> kernel module? and I just don't know whether should I start reading
>> >> articles about mesa hacking or about dri architecture or about kernel
>> >> module development.
>> >>
>> >> Now I think the best thing for me is to start looking through radeon
>> >> kernel
>> >> module code (I've got ingenious idea that power management resides there)
>> >> and read more about its architecture. Is this right? I mean, I just want
>> >> to
>> >> find out, is this a right place to start looking at for this bug?
>> >
>> > The power management is handled in the kernel driver.  See radeon_pm.c
>> > and the relevant *_dpm.c files depending on what asic you have.
>> >
>> > Alex
>> >
>> >> P.S. Sorry for my English in case it's not good, I'm learning it now
>> >>
>> >> P.P.S. And thanks for your hard work!
>> >>
>> >> ---
>> >> [1] https://bugs.freedesktop.org/show_bug.cgi?id=79806
>> >>
>> >> ___
>> >> dri-devel mailing list
>> >> dri-devel at lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

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

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

--- Comment #13 from Michel D?nzer  ---
You didn't do anything particularly wrong (though note that for the frames that
say libGL.so.1.2.0@*, you need to pass libGL.so.1.2.0 instead of r600_dri.so to
addr2line), but the resolved source code lines don't seem to have any sensible
correspondence. :( Are you sure Firefox was using the same
/usr/lib/x86_64-linux-gnu/dri/r600_dri.so file when it crashed?

Would it be possible for you to run Firefox in gdb, reproduce the crash and
then attach the output of bt full?

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

How to design a DRM KMS driver exposing 2D compositing?

[Matt Roper]

On Mon, Aug 11, 2014 at 01:38:55PM +0300, Pekka Paalanen wrote:
> Hi,
> 
> there is some hardware than can do 2D compositing with an arbitrary
> number of planes. I'm not sure what the absolute maximum number of
> planes is, but for the discussion, let's say it is 100.
> 
> There are many complicated, dynamic constraints on how many, what size,
> etc. planes can be used at once. A driver would be able to check those
> before kicking the 2D compositing engine.
> 
> The 2D compositing engine in the best case (only few planes used) is
> able to composite on the fly in scanout, just like the usual overlay
> hardware blocks in CRTCs. When the composition complexity goes up, the
> driver can fall back to compositing into a buffer rather than on the
> fly in scanout. This fallback needs to be completely transparent to the
> user space, implying only additional latency if anything.

Is your requirement that this needs to be transparent to all userspace
or just transparent to your display server (e.g., Weston)?  I'm
wondering whether it might be easier to write a libdrm interposer that
intercepts any libdrm calls dealing with planes and exposes a bunch of
additional "virtual" planes to the display server when queried.  When
you submit an atomic ioctl, your interposer will figure out the best
strategy to make that happen given the real hardware available on your
system and will try to blend some of your excess buffers via whatever
userspace API's are available (Cairo, GLES, OpenVG, etc.).  This would
keep kernel complexity down and allow easier debugging and tuning.


Matt

> These 2D compositing features should be exposed to user space through a
> standard kernel ABI, hopefully an existing ABI in the very near future
> like the KMS atomic.
> 
> Assuming the DRM universal planes and atomic mode setting / page flip
> infrastructure is in place, could the 2D compositing capabilities be
> exposed through universal planes? We can assume that plane properties
> are enough to describe all the compositing parameters.
> 
> Atomic updates are needed so that the complicated constraints can be
> checked, and user space can try to reduce the composition complexity if
> the kernel driver sees that it won't work.
> 
> Would it be feasible to generate a hundred identical non-primary planes
> to be exposed to user space via DRM?
> 
> If that could be done, the kernel driver could just use the existing
> kernel/user ABIs without having to invent something new, and programs
> like a Wayland compositor would not need to be coded specifically for
> this hardware.
> 
> What problems do you see with this plan?
> Are any of those problems unfixable or simply prohibitive?
> 
> I have some concerns, which I am not sure will actually be a problem:
> - Does allocating a 100 planes eat too much kernel memory?
>   I mean just the bookkeeping, properties, etc.
> - Would such an amount of planes make some in-kernel algorithms slow
>   (particularly in DRM common code)?
> - Considering how user space discovers all DRM resources, would this
>   make a compositor "slow" to start?
> 
> I suppose whether these turn out to be prohibitive or not, one just has
> to implement it and see. It should be usable on a slowish CPU with
> unimpressive amounts of RAM, because that is where a separate 2D
> compositing engine gives the most kick.
> 
> FWIW, dynamically created/destroyed planes would probably not be the
> answer. The kernel driver cannot decide before-hand how many planes it
> can expose. How many planes can be used depends completely on how user
> space decides to use them. Therefore I believe it should expose the
> maximum number always, whether there is any real use case that could
> actually get them all running or not.
> 
> What if I cannot even pick a maximum number of planes, but wanted to
> (as the hardware allows) let the 2D compositing scale up basically
> unlimited while becoming just slower and slower?
> 
> I think at that point one would be looking at a rendering API really,
> rather than a KMS API, so it's probably out of scope. Where is the line
> between KMS 2D compositing with planes vs. 2D composite rendering?
> 
> Should I really be designing a driver-specific compositing API instead,
> similar to what the Mesa OpenGL implementations use? Then have user
> space maybe use the user space driver part via OpenWFC perhaps?
> And when I mention OpenWFC, you probably notice, that I am not aware of
> any standard user space API I could be implementing here. ;-)
> 
> 
> Thanks,
> pq
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[Guenter Roeck]

On 08/11/2014 04:45 AM, David Rientjes wrote:
> On Sun, 10 Aug 2014, Guenter Roeck wrote:
>
>> spin_is_locked() always returns false in uniprocessor configurations
>> and can therefore not be used with BUG_ON. Replace it with
>> assert_spin_locked(), which exists for that very purpose.
>>
>
> It may be helpful to assess whether any of these sites should be converted
> to lockdep_assert_held() so they have no cost when lockdep isn't enabled
> but still reveal problems when debugging.
>
>

Possibly, but that would need to be done by someone with better knowledge
about locking and the code than me.

Guenter

[Bug 72685] [radeonsi hyperz] Artifacts in Unigine Sanctuary

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

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

--- Comment #20 from Michel D?nzer  ---
(In reply to comment #18)
>  So if someone succesfully fix that currently in various ways broken shadows
> setup in r600/radeonsi code, he will fix hyperz artifacts too :).

It's not that simple unfortunately. At least in Sanctuary, the shadows work
perfectly now without HyperZ but are still broken with 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/20140811/06812fda/attachment-0001.html>

[Bug 50135] Unigine Heaven black stripes and weird shaders

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

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

--- Comment #14 from Michel D?nzer  ---
Is this still an issue with current Mesa?

-- 
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/20140811/33a5466f/attachment.html>

[PATCH] drm: Do not use BUG_ON(!spin_is_locked())

[David Rientjes]

On Sun, 10 Aug 2014, Guenter Roeck wrote:

> spin_is_locked() always returns false in uniprocessor configurations
> and can therefore not be used with BUG_ON. Replace it with
> assert_spin_locked(), which exists for that very purpose.
> 

It may be helpful to assess whether any of these sites should be converted 
to lockdep_assert_held() so they have no cost when lockdep isn't enabled 
but still reveal problems when debugging.

[Bug 67681] Asus G75VW F key Not Working For Screen Brightness

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

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

--- Comment #31 from KernelBug <3fdd1e5d at opayq.com> ---
I wonder if any of the developers are aware that there is not one distro this
works on? Meaning there isn't the support for it in Linux, which I was hoping
was going to come from the kernel support.

I'm now using 3.16 and this still does not work... :(

>From the command line nothing works, the below command does not work.

echo 10 > /sys/class/backlight/asus-nb-wmi/brightness

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

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

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

--- Comment #6 from Michel D?nzer  ---
(In reply to comment #5)
> I tried adding R600_DEBUG=fs but no extra info was printed.

That should be R600_DEBUG=ps for the pixel/fragment shader (you can see a list
of supported debugging options with R600_DEBUG=help).

Anyway, this is probably related to comment #3.

-- 
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/20140811/447cd74f/attachment.html>

Looking for a start point for fixing a bug

[Адонай Элохим]

Hello again, hope you are still reading my texts...

I digged through the code and narrowed down the issue I wanted to fix.
It appears to be related to the `bool thermal_active` dpm struct
member and this piece of code:

if (rdev->asic->dpm.force_performance_level) {
if (rdev->pm.dpm.thermal_active) {
enum radeon_dpm_forced_level level = rdev->pm.dpm.forced_level;
/* force low perf level for thermal */
radeon_dpm_force_performance_level(rdev,
RADEON_DPM_FORCED_LEVEL_LOW);
/* save the user's level */
rdev->pm.dpm.forced_level = level;
} else {
/* otherwise, user selected level */
radeon_dpm_force_performance_level(rdev, rdev->pm.dpm.forced_level);
}
}

I did a double check here - at boot `thermal_active` is `false` and
thus, performance level is properly initiated. But at resume from
suspend `thermal_active` is true and performance level is strictly
bound to low profile.
Besides you cannot change it via echo 1 > /sys/.../force_dpm_level,
again thanks to `thermal_active` checked there.

Could you explain meaning of this small boolean to me? I'd like to
make a small neat patch fixing this, but I'm scared of doing it in
wrong way.
Sorry if I'm being too persistent.

Thanks,
Oleg

2014-07-22 20:05 GMT+04:00 Alex Deucher :
> On Tue, Jul 22, 2014 at 8:39 AM, ?? ??  wrote:
>> Hello all!
>>
>> I have some spare time and knowledge in C to try to fix some bugs I am
>> seeing on my machine.
>> So I've checked out and compiled all git trees that I may need and now I'm
>> beginning to read articles.
>>
>> And this is the point from where I don't know where to go. I want to fix
>> particular bug #79806 [1].
>> For me there are many places where this bug can hide - mesa? dri? radeon
>> kernel module? and I just don't know whether should I start reading articles
>> about mesa hacking or about dri architecture or about kernel module
>> development.
>>
>> Now I think the best thing for me is to start looking through radeon kernel
>> module code (I've got ingenious idea that power management resides there)
>> and read more about its architecture. Is this right? I mean, I just want to
>> find out, is this a right place to start looking at for this bug?
>
> The power management is handled in the kernel driver.  See radeon_pm.c
> and the relevant *_dpm.c files depending on what asic you have.
>
> Alex
>
>>
>> P.S. Sorry for my English in case it's not good, I'm learning it now
>>
>> P.P.S. And thanks for your hard work!
>>
>> ---
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=79806
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>