To plug the VRAM memory leak (see previous patch for
details) we must unpin the frame buffer when disabling the
CRTC. This warrants the addition of disable function for legacy
CRTC, which puts the CRTC in DPMS-OFF state and unpins the
frame buffer if there is one associated with the CRTC.
Signed-o
When drm_helper_disable_unused_functions calls disable
function of the CRTC, it also sets the crtc->fb pointer
to NULL. This can later (when the mode on that CRTC is setup
again from user space) cause ***_do_set_base functions to
"think" that there is no old buffer and skip the unpinning
code. Cons
The following patches will plug the VRAM leak that can be provoked in the
radeon driver by changing the mode. The mechanism that causes the leak is
described in the commit message associated with the first patch.
The way I have caused it (and tested the fix) was temporarily hack up debug
counters
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/37db41dc/attachment-0001.html>
archives/dri-devel/attachments/20131102/095eb3a1/attachment.html>
|--- |WONTFIX
--
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/20131102/857c5cc9/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131102/3169a3ee/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/f61937e6/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/c5123afd/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/076286d4/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/e4c0cefa/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-dma-fence-fixes.patch
Type: text/x-patch
Size: 4962 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/45c10588/attachment.bin>
ML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/d9920787/attachment.html>
pll clock may not match target clock exactly).
Not sure without testing which is worse, rounted (wrong) CTS or very slightly
slower/faster audio compared to video.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML at
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/20131102/8b1a7852/attachment-0001.html>
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/20131102/3f337265/attachment.html>
s scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/6a6692eb/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/268e27ce/attachment.html>
likely never tested.
As for the out of spec one, that would be 640x480 at 60/1.001 Hz.
--
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-dev
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/cad5a450/attachment.html>
ives/dri-devel/attachments/20131102/9733f515/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60523
--- Comment #44 from Tobias Droste ---
I see you want to enable DPM by default. Are there any news on this one? Should
I (we) try the drm-next branch to see if it is fixed? It's still an issue on
the drm-fixes branch from airlied.
--
You are rec
t?usp=sharing
Look at mirror: it's day 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/20131102/a390ae6f/attachment.html>
u 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/20131102/34da6bb9/attachment.html>
02.11.2013 03:01, Rafa? Mi?ecki kirjoitti:
> 2013/10/29 Anssi Hannula :
>> Fix the code to pick the PCM SAD with the highest number of channels,
>> while merging the rate masks of PCM SADs with lower amount of channels
>> into the additional stereo rate mask byte.
>
> Don't you think that we shoul
2013/11/2 Anssi Hannula :
> SAD with channels=6,freqs=32..96kHz,bits=16..24 implies that those freqs
> and bps are supported for all channel counts up to 6 (since it is "Max
> Number of channels"). Therefore the specified rates are supported in
> stereo mode as well and I believe should be included
2013/10/29 Anssi Hannula :
> + if (sad->channels > max_channels) {
> + value = MAX_CHANNELS(sad->channels) |
> + DESCRIPTOR_BYTE_2(sad->byte2)
> |
> +
2013/10/29 Anssi Hannula :
> Fix the code to pick the PCM SAD with the highest number of channels,
> while merging the rate masks of PCM SADs with lower amount of channels
> into the additional stereo rate mask byte.
Don't you think that we should use SUPPORTED_FREQUENCIES_STEREO for
stereo freque
2013/11/1 Dave Airlie :
>>> After looking at some of the ordering issues we've had with x86 GPUs
>>> (which are really just a tightly coupled SoC) I don't want separate
>>> drivers all having their own init, suspend/resume paths in them as I
>>> know we'll have to start making special vtable entry
29 matches
Mail list logo
