outcome of DRM/KMS DT bindings session
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 points etc to >>> solve some random ordering issues that crop up. >> >> The DRM device has to be initialized/suspended/resumed as a whole, no >> doubt about that. If that's not the case you indeed open up the door for >> all kinds of ordering issues. >> >> Still the different components can be multiple devices, just initialize >> the drm device once all components are probed. Remove it again once a >> component is removed. Handle suspend in the DRM device, not in >> the individual component drivers. The suspend in the component drivers >> would only be called after the DRM device is completely quiesced. >> Similarly the resume in the component drivers would not reenable the >> components, this instead would be done in the DRM device when all >> components are there again. > > But why? why should we have separate drivers for each component of a > tightly coupled SoC? > > it makes no sense, having a driver node per every block in the chip > isn't an advantage, it complicates > things for no advantage at all. If we don't have hotplug hw removing > one device shouldn't be possible > this idea that removing a sub-driver should teardown the drm is crazy as well. > >> >> This way all components could be proper (driver model)devices with >> proper drivers without DRM even noticing that multiple components are >> involved. >> >> Side note: We have no choice anyway. All SoCs can (sometimes must) >> be extended with external I2C devices. On every SoC the I2C bus master >> is a separate device, so we have a multicomponent device (in the sense >> of driver model) already in many cases. >> > > Having off-chip i2c devices being part of the driver model is fine, > stuff works like that everywhere, > having each SoC block part of the device model isn't fine unless you > can really prove re-use and > why having separate driver templating for each block is helpful. > > I'm not willing to have overly generic sub drivers that provide no > advantage and only add lots > of disadvantage like init and suspend/resume ordering. I know there is > going to be SoC ordering > issues at init time that will end up circular between two separate > drivers each deferring because > they want another driver up. Don't dig us into that hole, i2c has a > well defined ordering of init, > I don't think internal SoC devices are so well defined. > It seems that the main reason we should go to a single drm driver is the probe ordering issue of sub drivers and the power ordering issue of them. First, I'd like to ask qustions to myself and other people. Do we really need to define the display pipeline node? Is there really any good way to can use only existing device nodes? Please suppose the below things, 1. crtc and encoder/connector can be created when KMS driver and display driver are probed regardless of the ordering 2. A crtc and a connector are connected when last one is created. This means that a framebuffer will be created and the framebuffer's image will be transferred to display via KMS driver. And let see how hardware pipe lines can be linked each other, 1. Top level CRTC Encoder -- Connector 2. CRTC Display controller or HDMI Display controller or HDMI -- Image Enhancement chips or other 3. Encoder/Connector LCD Panel Display bus(mipi, dp) --- LCD panel or TV Display bus(mipi, dp) --- bridge device(lvds) --- LCD panel or TV As you can see the above, if a crtc and a connector could be connected each other regardless of the probe order - actually possible, and we are already using this way in internal project - then I think it's enough to consider display pipeline node to CRTC, and to Encoder/Connector individually. DT binding of CRTC including Image Enhancement chips can be done at top level of drm driver, and DT binding of Encoder/Connector including bridge device and panel can be done at probe of separated encoder/connector driver. Of course, for avoiding power ordering issue, each encoder/connector drivers shouldn't have their resume/suspend interfaces, and their pm should be handled by dpms callback at top level of drm driver. This way I think we could simplify to compose the display pipeline node as device tree,and also we could have a separated device driver as driver model. Thanks, Inki Dae > Dave. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases
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 frequencies only? > if (sad->format == HDMI_AUDIO_CODING_TYPE_PCM) > + stereo_freqs |= sad->freq; I mean making that (... && sad->channels == 1)
[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases
2013/10/29 Anssi Hannula :
> + if (sad->channels > max_channels) {
> + value = MAX_CHANNELS(sad->channels) |
> + DESCRIPTOR_BYTE_2(sad->byte2)
> |
> +
> SUPPORTED_FREQUENCIES(sad->freq);
> + max_channels = sad->channels;
> + }
Just for a record. I was wondering if fglrx sets both:
SUPPORTED_FREQUENCIES and SUPPORTED_FREQUENCIES_STEREO for receiver
with LPCM stereo only. It does:
5f84 07070701 (117901057)
5f88 (0)
5f8c (0)
5f90 (0)
5f94 (0)
5f98 (0)
5f9c (0)
5fa0 (0)
5fa4 (0)
5fa8 (0)
5fac (0)
5fb0 (0)
5fb4 (0)
5fb8 (0)
So with the above code we'll be compatible with fglrx about that.
Nice. Just wanted to note that :)
[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases
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 should use SUPPORTED_FREQUENCIES_STEREO for > stereo frequencies only? > > >> if (sad->format == >> HDMI_AUDIO_CODING_TYPE_PCM) >> + stereo_freqs |= sad->freq; > > I mean making that (... && sad->channels == 1) > 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 in the stereo bitmask. As per AMD HDA Verbs documentation the 4th byte is "Rates supported for stereo". And since those rates _are_ supported by stereo, IMO they should be there. -- Anssi Hannula
[PATCH] drm/radeon/audio: fix missing multichannel PCM SAD in some cases
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 in the stereo bitmask. > > As per AMD HDA Verbs documentation the 4th byte is "Rates supported for > stereo". And since those rates _are_ supported by stereo, IMO they > should be there. OK, that sounds sane. Thanks for explaining. Acked-by: Rafa? Mi?ecki -- Rafa?
[Bug 71156] New: [radeonsi] [r600g] Euro Truck Simulator 2 wrong color
https://bugs.freedesktop.org/show_bug.cgi?id=71156 Priority: medium Bug ID: 71156 Assignee: dri-devel at lists.freedesktop.org Summary: [radeonsi] [r600g] Euro Truck Simulator 2 wrong color Severity: normal Classification: Unclassified OS: Linux (All) Reporter: step2back+freedesktop at gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Euro Truck Simulator 2 1.5 from steam. I tested booth HD6450 and HD7770 same effect. Game looks like at night, but it's day. I used CATALYST driver before. I got mesa from https://launchpad.net/~oibaf/+archive/graphics-drivers https://launchpad.net/~oibaf/+archive/graphics-drivers/+sourcepub/3631401/+listing-archive-extra https://launchpad.net/~oibaf/+archive/graphics-drivers/+sourcepub/3616730/+listing-archive-extra https://launchpad.net/~oibaf/+archive/graphics-drivers/+sourcepub/3628102/+listing-archive-extra $ uname -a Linux silverstone 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- 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/34da6bb9/attachment.html>
[Bug 71156] [radeonsi] [r600g] Euro Truck Simulator 2 wrong color
https://bugs.freedesktop.org/show_bug.cgi?id=71156 --- Comment #1 from Stepan Bakshaev --- I can't attach screenshot. I post links HD7770 https://drive.google.com/file/d/0BytXisVUnJ7QSzlxV2NkS1B2LTQ/edit?usp=sharing HD6450 https://drive.google.com/file/d/0BytXisVUnJ7QbktjcVhNWHVTQ1k/edit?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>
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
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 receiving this mail because: You are watching the assignee of the bug.
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #148 from 720 --- Read that DPM is coming to 3.13. The issue is still not fixed however. Any info on this? Is there a chance that it will ever get fixed? ( I followed the conversation but so far it seemed Alex wasn't able to track down the issue, and could only apply workarounds that literally disable the whole power management. ) -- 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/9733f515/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #41 from Peter Fr?hberger --- I tested on a 3.12-rc7+ kernel in the following combination: a) sw cts/n values revert + pierre ossman patch applied All fine - watched a whole 24p movie with dts-hd b) kept 3.12-rc7+ as is and only applied pierre ossman patch All fine I think with a) the "table" was used and with b) the values were calculated. So both seem fine. I am a bit afraid with the "out of spec" values - but it did not harm here and the kernel print did not happen. -- 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/cad5a450/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #42 from Pierre Ossman --- (In reply to comment #41) > I think with a) the "table" was used and with b) the values were calculated. > So both seem fine. I am a bit afraid with the "out of spec" values - but it > did not harm here and the kernel print did not happen. Actually, I believe with a) the sw values (table, calculated or otherwise) are ignored and the hw does its own thing. With b) you will most likely use the table since all common modes will be in that table. So the calculation was most 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-devel/attachments/20131102/e7354194/attachment.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #43 from Pierre Ossman --- (In reply to comment #40) > > 1. The 25175 clock at 44.1 kHz is out of spec. There are no correct values > > to > > make it in spec. So either change the clock, rely on hw calculated values, > > or > > hope that sinks tolerate the large N. > > 4th alternative is to round CTS and leave the glitches in on those modes. I > might even slightly prefer that than produce out-of-spec N, but that is just > my preference and I don't really have any real-world data of course... If we truncate the clock to 25274 instead instead of rounding it up, we can get sensible N/CTS. Is that something that's possible to do? I don't know how the code that generates the clock looks like. -- 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/268e27ce/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #149 from Paul Bodenbenner --- I think dpm won't be enabled per default for 3.13 on hd3XXX... The boot bug is a real big problem. Sometimes it works two or three times, sometimes it takes three tries for a success. Also waking up from suspend doesn't work all the time. Catalyst is broken with Gnome Shell 3.10... What a suprise. Real good experience at the moment with ATI/AMD! :-) -- 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/6a6692eb/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #150 from 720 --- Too bad there is no quirk or some dirty workaround that we could use to fix the boot issue. Because damn, it's not cheap to replace a laptop. (Which works just perfect on Windows 7.) -- 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/3f337265/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #151 from Paul Bodenbenner --- I respect all the good work what has been done in the past for the AMD driver. But probably they have no hd3XXX card to test the driver. I would pay 20? for getting them a card... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/8b1a7852/attachment-0001.html>
[Bug 69675] audio broken in 24Hz/24p since 3.11 (regression)
https://bugs.freedesktop.org/show_bug.cgi?id=69675 --- Comment #44 from Anssi Hannula --- (In reply to comment #43) > (In reply to comment #40) > > > 1. The 25175 clock at 44.1 kHz is out of spec. There are no correct > > > values to > > > make it in spec. So either change the clock, rely on hw calculated > > > values, or > > > hope that sinks tolerate the large N. > > > > 4th alternative is to round CTS and leave the glitches in on those modes. I > > might even slightly prefer that than produce out-of-spec N, but that is just > > my preference and I don't really have any real-world data of course... > > If we truncate the clock to 25274 instead instead of rounding it up, we can > get sensible N/CTS. Is that something that's possible to do? I don't know > how the code that generates the clock looks like. I don't think it makes sense to massage the video clock to get integer CTS. After all, the clock can come from other sources as well (user modeline, EDID...). However, there's a similar 6th alternative: Massage the target clock frequency that is used by r600_hdmi_acr() and r600_audio_set_dto() (and evergreen_audio_set_dto()) so that an integer CTS is achieved. This will cause the CTS to be correct and in-spec, but the audio speed will be on the order of ~0.004% slower/faster than video (remember that video+audio may not be this accurate otherwise either, as 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 attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131102/085e95e5/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #152 from 720 --- (In reply to comment #151) > I respect all the good work what has been done in the past for the AMD > driver. > But probably they have no hd3XXX card to test the driver. I would pay 20? > for getting them a card... Fine with me. If Alex is willing to make a paypal address or something, I'll throw a few bucks in too. These cards are old as hell, he can buy them in bulk. -- 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/d9920787/attachment.html>
[Bug 71050] Libreoffice crashes with segfault in r600_dri.so
https://bugs.freedesktop.org/show_bug.cgi?id=71050 --- Comment #6 from Rpnpif --- Same issues with some slide transitions in Impress of LibreOffice 4.1.3.2. -- 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/e4c0cefa/attachment.html>
[Bug 39308] mplayer -vo vdpau draws incorrectly on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39308 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Marek Ol??k --- VDPAU support has been removed and it's not very useful on these GPUs. -- 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/076286d4/attachment.html>
[Bug 39309] vdpau decodes noise on rv350
https://bugs.freedesktop.org/show_bug.cgi?id=39309 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #15 from Marek Ol??k --- VDPAU support has been removed and it's not very useful on these GPUs anyway. -- 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/c5123afd/attachment.html>
[Bug 48746] radeon express 1250 and vdpau doesn't work for interlaced sample in mplayer.
https://bugs.freedesktop.org/show_bug.cgi?id=48746 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Marek Ol??k --- VDPAU support has been removed and it's not very useful on these GPUs anyway. -- 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/f61937e6/attachment.html>
[Bug 39782] [r300g] XvMC playback fails with MPEG2 video and RV350
https://bugs.freedesktop.org/show_bug.cgi?id=39782 --- Comment #16 from Marek Ol??k --- XvMC support has been removed. -- 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/3169a3ee/attachment.html>
[Bug 39782] [r300g] XvMC playback fails with MPEG2 video and RV350
https://bugs.freedesktop.org/show_bug.cgi?id=39782 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |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>
[Bug 61349] [r300g, bisected] piglit rgtc-teximage-01 fails
https://bugs.freedesktop.org/show_bug.cgi?id=61349 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Ol??k --- Closing, because it's a hardware limitation. -- 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/095eb3a1/attachment.html>
[Bug 61349] [r300g, bisected] piglit rgtc-teximage-01 fails
https://bugs.freedesktop.org/show_bug.cgi?id=61349 Marek Ol??k changed: What|Removed |Added Resolution|FIXED |NOTABUG -- 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/37db41dc/attachment-0001.html>
plug the VRAM leak in radeon driver
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 in radeon_bo_pin and radeon_bo_unpin functions. Then I connected two monitor one of which had 1600x1200 for preferred mode, while the other had preferred mode of the other monitor was 1280x720. Then I repetitively unplugged and plugged back the 1600x1200 monitor and ran 'xrandr --auto' between each plug/unplug operation. Without the fix, the number of pinned buffers grew at each plug/unplug operation. With the fix, the counter remained stable throughout the test. Note that I only effectively tested the first patch, because I don't have any GPUs that are old enough to use the legacy CRTC path in the driver. Still, based on my findings for AtomBIOS GPUs, I believe that the second patch is correct and necessary. regards, Ilija
[PATCH 1/2] drm/radeon/kms: unpin fb in atombios crtc disable
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. Consequently, the buffer that has been NULL-ified in
drm_helper_disable_unused_functions will never be unpinned
causing a leak in VRAM.
This patch plugs the leak by unpinning the frame buffer
in crtc_disable function.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/atombios_crtc.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index bf87f6d..9eb24a3 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1910,6 +1910,21 @@ static void atombios_crtc_disable(struct drm_crtc *crtc)
int i;
atombios_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
+ if (crtc->fb) {
+ int r;
+ struct radeon_framebuffer *radeon_fb;
+ struct radeon_bo *rbo;
+
+ radeon_fb = to_radeon_framebuffer(crtc->fb);
+ rbo = gem_to_radeon_bo(radeon_fb->obj);
+ r = radeon_bo_reserve(rbo, false);
+ if (unlikely(r))
+ DRM_ERROR("failed to reserve rbo before unpin\n");
+ else {
+ radeon_bo_unpin(rbo);
+ radeon_bo_unreserve(rbo);
+ }
+ }
/* disable the GRPH */
if (ASIC_IS_DCE4(rdev))
WREG32(EVERGREEN_GRPH_ENABLE + radeon_crtc->crtc_offset, 0);
--
1.8.2.1
[PATCH 2/2] drm/radeon/kms: add crtc_disable function for legacy crtc
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-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index 7cb178a..0c7b8c6 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -1056,6 +1056,26 @@ static void radeon_crtc_commit(struct drm_crtc *crtc)
}
}
+static void radeon_crtc_disable(struct drm_crtc *crtc)
+{
+ radeon_crtc_dpms(crtc, DRM_MODE_DPMS_OFF);
+ if (crtc->fb) {
+ int r;
+ struct radeon_framebuffer *radeon_fb;
+ struct radeon_bo *rbo;
+
+ radeon_fb = to_radeon_framebuffer(crtc->fb);
+ rbo = gem_to_radeon_bo(radeon_fb->obj);
+ r = radeon_bo_reserve(rbo, false);
+ if (unlikely(r))
+ DRM_ERROR("failed to reserve rbo before unpin\n");
+ else {
+ radeon_bo_unpin(rbo);
+ radeon_bo_unreserve(rbo);
+ }
+ }
+}
+
static const struct drm_crtc_helper_funcs legacy_helper_funcs = {
.dpms = radeon_crtc_dpms,
.mode_fixup = radeon_crtc_mode_fixup,
@@ -1065,6 +1085,7 @@ static const struct drm_crtc_helper_funcs
legacy_helper_funcs = {
.prepare = radeon_crtc_prepare,
.commit = radeon_crtc_commit,
.load_lut = radeon_crtc_load_lut,
+ .disable = radeon_crtc_disable
};
--
1.8.2.1
[Linaro-mm-sig] thoughts of looking at android fences
On Wed, Oct 30, 2013 at 5:17 AM, Maarten Lankhorst wrote: > op 24-10-13 14:13, Maarten Lankhorst schreef: >> So I actually tried to implement it now. I killed all the deprecated members >> and assumed a linear timeline. >> This means that syncpoints can only be added at the end, not in between. In >> particular it means sw_sync >> might be slightly broken. >> >> I only tested it with a simple program I wrote called ufence.c, it's in >> drivers/staging/android/ufence.c in the following tree: >> >> http://cgit.freedesktop.org/~mlankhorst/linux >> >> the "rfc: convert android to fence api" has all the changes from my >> dma-fence proposal to what android would need, >> it also converts the userspace fence api to use the dma-fence api. >> >> sync_pt is implemented as fence too. This meant not having to convert all of >> android right away, though I did make some changes. >> I killed the deprecated members and made all the fence calls forward to the >> sync_timeline_ops. dup and compare are no longer used. >> >> I haven't given this a spin on a full android kernel, only with the >> components that are in mainline kernel under staging and my dumb test >> program. >> >> ~Maarten >> >> PS: The nomenclature is very confusing. I want to rename dma-fence to >> syncpoint, but I want some feedback from the android devs first. :) >> > Come on, any feedback? I want to move the discussion forward. > > ~Maarten I experimented with it a little on a device that uses sync and came across a few bugs: 1. sync_timeline_signal needs to call __fence_signal on all signaled points on the timeline, not just the first 2. fence_add_callback doesn't always initialize cb.node 3. sync_fence_wait should take ms 4. sync_print_pt status printing was incorrect 5. there is a deadlock: sync_print_obj takes obj->child_list_lock sync_print_pt fence_is_signaled fence_signal takes fence->lock == obj->child_list_lock 6. freeing a timeline before all the fences holding points on that timeline have timed out results in a crash With the attached patch to fix these issues, our libsync and sync_test give the same results as with our sync code. I haven't tested against the full Android framework yet. The compare op and timeline ordering is critical to the efficiency of sync points on Android. The compare op is used when merging fences to drop all but the latest point on the same timeline. This is necessary for example when the same buffer is submitted to the display on multiple frames, like when there is a live wallpaper in the background updating at 60 fps and a static screen of widgets on top of it. The static widget buffer is submitted on every frame, returning a new fence each time. The compositor merges the new fence with the fence for the previous buffer, and because they are on the same timeline it merges down to a single point. I experimented with disabling the merge optimization on a Nexus 10, and found that leaving the screen on running a live wallpaper eventually resulted in 100k outstanding sync points. -- 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>
