[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #47 from Hohahiu --- The problem is fixed now in kernel 3.14-rc3. Truly speaking the laptop now is very cold compared to what it was before. So thank you very much for your work, Alex and Michel! However whenever my dGPU is powered on there are following error messages: [ 32.333940] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 33.357599] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 34.381217] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 35.404882] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 36.428483] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 37.452137] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 38.475777] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 39.499447] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 40.523078] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 41.546747] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 41.566826] [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!! [ 41.566879] [drm:si_startup] *ERROR* radeon: failed initializing UVD (-1). Is it related to this issue or do you want me to open new bug report? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #48 from Hohahiu --- Created attachment 126711 --> https://bugzilla.kernel.org/attachment.cgi?id=126711&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #49 from Alex Deucher --- (In reply to Hohahiu from comment #47) > [ 41.546747] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to > reset the VCPU!!! > [ 41.566826] [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!! > [ 41.566879] [drm:si_startup] *ERROR* radeon: failed initializing UVD (-1). > > Is it related to this issue or do you want me to open new bug report? Please open a different bug for this. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash
https://bugzilla.kernel.org/show_bug.cgi?id=65761 --- Comment #50 from Joshua M. Thompson --- On Fedora Rawhide kernel 3.14.0-0.rc3.git0.2.fc21.x86_64 still doesn't fix this (maybe it doesn't have the necessary patch yet?) With radeon.runpm=1 I get the "UVD not responding" messages, the machine locks up frequently for 5-10 seconds to reinit the radeon, and the radeon performance is horrible (~400 fps in glxgears). With radeon.runpm=0 I don't get "UVD not responding", the lockups are gone, and glxgears is at 3650 fps (still less than the 6-7k fps I got under 3.12 though.) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 Michel D?nzer changed: What|Removed |Added CC||janinko.g at gmail.com --- Comment #65 from Michel D?nzer --- *** Bug 74154 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/20140219/1c2d28ff/attachment.html>
AMD/AMD hybrid graphics
Hi, I just got a Lenovo Thinkpad Edge E545 notebook and I have installed Fedora 20/x86_64. The CPU is Richland A10-5750 (contains ARUBA graphics) and there is also a discrete HAINAN chip with 2GB dedicated memory on the mainboard. The problems started during installation, it looked like the machine was frozen when using KMS so I had to use VESA during installation. I was able to install from the network and the latest kernel upgrade is 3.13.3-201. So, I was happy at first when I removed "nomodeset" and it booted up properly in KMS mode and did so after the first few restarts. Initially lspci showed both cards. dmesg told me that HAINAN was not posted by the BIOS but the kernel did it and also loaded the firmware into both cards. Xorg used the integrated ARUBA chip only. Then I looked up info about PRIME and wanted to test it. However, "xrandr --listproviders" showed only one line and "DRI_PRIME=1 glxinfo64 | grep -i renderer" showed that Mesa is using the ARUBA chip regardless of the DRI_PRIME setting. I am sorry, I didn't save the xrandr output, so I can't prove it. Anyway, Xorg.0.log had only traces about the ARUBA, nothing about the discrete chip. Unfortunately, I didn't save neither dmesg nor Xorg.0.log at the time. The UEFI BIOS has a knob to switch between "Integrated Graphics" and "Switchable Graphics" and switchable was the default. There is another one for "OS detection for Switchable Graphics: enable/disable" I started playing with the BIOS settings and this was (or was it?) a mistake. (But this is how I discovered that the virtualization enabled/disabled setting in the BIOS is actually reversed and I also need KVM.) The result of changing to "Integrated Graphics" in the BIOS and changing back to "Switchable Graphics" and toggling the "OS detection" switch to disabled and back to enabled changed the system behavior. The symptom is that after systemd loaded all the services, the machine doesn't seem to do anything at first sight. The systemd messages are left on the screen but the X greeter (lightdm) doesn't show up. However, the system reacts to the power button and shuts down properly. This was encouraging and on the next boot I tried to ssh into the machine and successfully collect dmesg and Xorg logs. It turned out that now, when "Switchable Graphics" is active, regardless of the state of "OS detection for Switchable Graphics", Xorg initializes both cards and apparently wants to use the HAINAN to display the X screen but dies in the process: [zozo at localhost ~]$ ps auxw | grep Xorg root 626 0.0 0.0 209748 4320 ?Ss 08:51 0:00 /usr/bin/abrt-watch-log -F Backtrace /var/log/Xorg.0.log -- /usr/bin/abrt-dump-xorg -xD zozo 1245 0.0 0.0 112680 976 pts/0S+ 08:56 0:00 grep --color=auto Xorg [zozo at localhost ~]$ ps auxw | grep dm zozo 1247 0.0 0.0 112676 976 pts/0S+ 08:57 0:00 grep --color=auto dm Since this is a very new machine it seems footnote 5 from http://wiki.x.org/wiki/RadeonFeature/ applies and the HAINAN chip is not connected to the display output. So, currently I can only get it to display X when I use the "Integrated Graphics" setting in the BIOS. In this state, the discrete graphics chip doesn't even show up in lspci: [zozo at localhost ~]$ cat lspci-hainan-disabled 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Complex 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8650G] 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Trinity HDMI Audio Controller 00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 10h-1fh) Processor Root Port 00:10.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 09) 00:10.1 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller (rev 09) 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 40) 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI Controller (rev 11) 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB EHCI Controller (rev 11) 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 16) 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (rev 01) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 11) 00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] FCH PCI Bridge (rev 40) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h (Model
AMD/AMD hybrid graphics
On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: > > On second thought, the usage of VESA for installation and then > switching to KMS might have caused the mixed behaviour, i.e. that > the kernel recognized and initialized both chips but X used only the > integrated one. But I don't want to reinstall the system to test > this theory. I doubt it would make any difference. > Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and > RADEON(G0) lines (for HAINAN) are present. [...] > I would like to have PRIME functional so I will need to set "Switchable > Graphics" in the BIOS. What xorg.conf magic should I add to make it > use the ARUBA chip for display but still keep HAINAN active for PRIME? According to the screen enumeration above, that's already the case. https://bugs.freedesktop.org/show_bug.cgi?id=69694 may be helpful for troubleshooting the crash. > Can Mesa/Xorg use both r600g and radeonsi at the same time? Yes, that seems to work fine for others. You may need Mesa 10.1 or newer though. -- Earthling Michel D?nzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[PATCH] nouveau, ACPI: fix regression caused by b072e53
op 19-02-14 05:53, Jiang Liu schreef: > On some platforms, ACPI _DSM method (nouveau_op_dsm_muid, function 0) > has special requirements on the fourth parameter, which is different > from ACPI specifications. So revert to the private implementation > to check availability of _DSM functions instead of using common > acpi_check_dsm() interface. > > Signed-off-by: Jiang Liu > --- > Hi Maarten, > Thanks for bisecting. Could you please help to verify whether > this patch fixes the regression? > Tested-by: Maarten Lankhorst I was wrong about the operator precedence, seems correct after all. :-)
[PATCH 5/5] drm/i915: Add full pipe rotation
Reviewed-by: Sagar Kamble On Wed, 2014-02-12 at 23:15 +0200, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > We can pretend that we can rotate the entire pipe by rotating all the > planes and adjusting their positions appropriately. Add a "rotation" > property on the crtc which will do this. > > The main upshot of doing the full pipe rotation instead of rotating all > the planes individually is that the plane positions turn out correct > automagically. So userspace doesn't need to do anything except toggle > the property and continue as if nothing had changed. > > The actual implementation is pretty much trivial thanks to drm_rect > and drm_rotation_chain() ;) > > Cc: Sagar Kamble > Signed-off-by: Ville Syrj?l? > --- > drivers/gpu/drm/i915/i915_dma.c | 6 ++ > drivers/gpu/drm/i915/intel_display.c | 154 > +++ > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 6 +- > drivers/gpu/drm/i915/intel_sprite.c | 21 +++-- > 5 files changed, 164 insertions(+), 24 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > index 3dd9abb..b59bff1 100644 > --- a/drivers/gpu/drm/i915/i915_dma.c > +++ b/drivers/gpu/drm/i915/i915_dma.c > @@ -1914,6 +1914,12 @@ void i915_driver_lastclose(struct drm_device * dev) > dev_priv->rotation_property, > plane->rotation); > } > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, > base.head) { > + crtc->pipe_rotation = BIT(DRM_ROTATE_0); > + drm_object_property_set_value(&crtc->base.base, > + > dev_priv->rotation_property, > + crtc->pipe_rotation); > + } > } > > if (dev_priv->cursor_rotation_property) { > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index e94167b..1b74d24 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -39,6 +39,7 @@ > #include "i915_trace.h" > #include > #include > +#include > #include > > static void intel_increase_pllclock(struct drm_crtc *crtc); > @@ -2060,6 +2061,8 @@ static int i9xx_update_plane(struct drm_crtc *crtc, > struct drm_framebuffer *fb, > u32 dspcntr; > u32 reg; > int pixel_size; > + unsigned int rotation = drm_rotation_chain(intel_crtc->pipe_rotation, > + > intel_crtc->primary_rotation); > > switch (plane) { > case 0: > @@ -2133,7 +2136,7 @@ static int i9xx_update_plane(struct drm_crtc *crtc, > struct drm_framebuffer *fb, > intel_crtc->dspaddr_offset = linear_offset; > } > > - if (intel_crtc->primary_rotation == BIT(DRM_ROTATE_180)) { > + if (rotation == BIT(DRM_ROTATE_180)) { > dspcntr |= DISPPLANE_ROTATE_180; > > x += (intel_crtc->config.pipe_src_w - 1); > @@ -2173,6 +2176,8 @@ static int ironlake_update_plane(struct drm_crtc *crtc, > u32 dspcntr; > u32 reg; > int pixel_size; > + unsigned int rotation = drm_rotation_chain(intel_crtc->pipe_rotation, > + > intel_crtc->primary_rotation); > > switch (plane) { > case 0: > @@ -2238,7 +2243,7 @@ static int ironlake_update_plane(struct drm_crtc *crtc, > fb->pitches[0]); > linear_offset -= intel_crtc->dspaddr_offset; > > - if (intel_crtc->primary_rotation == BIT(DRM_ROTATE_180)) { > + if (rotation == BIT(DRM_ROTATE_180)) { > dspcntr |= DISPPLANE_ROTATE_180; > > if (!IS_HASWELL(dev) && !IS_BROADWELL(dev)) { > @@ -7468,6 +7473,8 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, > u32 base, bool force) > bool visible = base != 0; > > if (force || intel_crtc->cursor_visible != visible) { > + unsigned int rotation = > drm_rotation_chain(intel_crtc->pipe_rotation, > + > intel_crtc->cursor_rotation); > uint32_t cntl = I915_READ(CURCNTR(pipe)); > if (base) { > cntl &= ~(CURSOR_MODE | MCURSOR_PIPE_SELECT); > @@ -7477,7 +7484,7 @@ static void i9xx_update_cursor(struct drm_crtc *crtc, > u32 base, bool force) > cntl &= ~(CURSOR_MODE | MCURSOR_GAMMA_ENABLE); > cntl |= CURSOR_MODE_DISABLE; > } > - if (intel_crtc->cursor_rotation == BIT(DRM_ROTATE_180)) > + if (rotation == BIT(DRM_ROTATE_180)) > cntl |= CURSOR_ROTATE_180; > else > cntl &= ~CURSOR_ROTATE_180; > @@ -7500,6 +7507,8 @@ st
[PATCH] drm/exynos: restore core HDMI settings
2014-02-14 16:34 GMT+09:00 Shirish S : > In DVI mode the video preamble and Guard band should > be disabled whereas it should be applied in HDMI mode, > the re-applying of preamble and guard band was missing, > which resulted in display failures when switched to HDMI > mode from DVI mode. > This patch ensures the setting is applied in HDMI mode. > > Signed-off-by: Shirish S > --- > drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index a0e10ae..a102076 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -994,6 +994,8 @@ static void hdmi_conf_init(struct hdmi_context *hdata) > /* choose HDMI mode */ > hdmi_reg_writemask(hdata, HDMI_MODE_SEL, > HDMI_MODE_HDMI_EN, HDMI_MODE_MASK); > + /* Apply Video preable and Guard band in HDMI mode only */ > + hdmi_reg_writeb(hdata, HDMI_CON_2, 0); Isn't hdmi_conf_init function always called after hdmi core is reset? And HDMI_CON_2 would have 0 as reset value. It seems that your code isn't meaningful. If you want to set HDMI_CON_2 to HDMI mode in there then it would better to use meaningful macro, HDMI_VID_PREAMBLE_DIS and HDMI_GUARD_BAND_DIS. Thanks, Inki Dae > /* disable bluescreen */ > hdmi_reg_writemask(hdata, HDMI_CON_0, 0, HDMI_BLUE_SCR_EN); > > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
AMD/AMD hybrid graphics
2014-02-19 10:59 keltez?ssel, Michel D?nzer ?rta: > On Mit, 2014-02-19 at 09:11 +0100, Boszormenyi Zoltan wrote: >> On second thought, the usage of VESA for installation and then >> switching to KMS might have caused the mixed behaviour, i.e. that >> the kernel recognized and initialized both chips but X used only the >> integrated one. But I don't want to reinstall the system to test >> this theory. > I doubt it would make any difference. > > >> Now, with the "Switchable" state, RADEON(0) lines (for ARUBA) and >> RADEON(G0) lines (for HAINAN) are present. > [...] >> I would like to have PRIME functional so I will need to set "Switchable >> Graphics" in the BIOS. What xorg.conf magic should I add to make it >> use the ARUBA chip for display but still keep HAINAN active for PRIME? > According to the screen enumeration above, that's already the case. I see. > https://bugs.freedesktop.org/show_bug.cgi?id=69694 may be helpful for > troubleshooting the crash. I looked at it and the symptoms from comment 17 and comment 19 (blank screen with only the cursor visible) looks like it's very similar to my case. Only when removing the "quiet" kernel command line option, more is left visible on the screen, not just the cursor. >> Can Mesa/Xorg use both r600g and radeonsi at the same time? > Yes, that seems to work fine for others. You may need Mesa 10.1 or newer > though. Do you mean mean with Mesa 9.2.5 and Xorg server 1.14.4 in Fedora 20 at this time, it's not possible unless I compile my own llvm-3.5 SVN, Mesa 10.1 or 10.2 GIT and Xorg 1.15 GIT? I tried to upgrade to rawhide at least in part: [zozo at localhost ~]$ rpm -q kernel mesa-libGL xorg-x11-server-Xorg llvm-libs kernel-3.13.3-201.fc20.x86_64 mesa-libGL-10.1-0.rc1.20140208.fc21.x86_64 mesa-libGL-10.1-0.rc1.20140208.fc21.i686 xorg-x11-server-Xorg-1.15.0-3.fc21.x86_64 llvm-libs-3.4-4.fc21.x86_64 llvm-libs-3.4-4.fc21.i686 I still get the same problem. Attached is the log from both 1.14.4 (FC20) and 1.15.0 (rawhide), with this change so the timing info is cut off from the beginning of each line to make it easier to produce a diff between the two files: [zozo at localhost ~]$ cat Xorg.0.log.hainan-active | cut -d ']' -f 2- >Xorg.0.log.hainan-active-no-timing [zozo at localhost ~]$ cat /var/log/Xorg.0.log | cut -d ']' -f 2- >Xorg.0.log.hainan-active-no-timing-1.15 Best regards, Zolt?n B?sz?rm?nyi -- next part -- A non-text attachment was scrubbed... Name: Xorg.0.log.hainan-active-no-timing.gz Type: application/x-tar Size: 6728 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/898dc406/attachment-0002.tar> -- next part -- A non-text attachment was scrubbed... Name: Xorg.0.log.hainan-active-no-timing-1.15.gz Type: application/x-tar Size: 6738 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/898dc406/attachment-0003.tar>
[PATCH v4 14/34] drm/exynos: hdmi: remove the i2c drivers and use devtree
Hi Tomasz, 2014-02-14 23:13 GMT+09:00 Tomasz Stanislawski : > Hi Daniel, > I think that it would be better to change the semantic of phy and ddc > bindings. > > Rather than pointing to I2C client it should point to I2C bus instead. > The exynos DRM driver can create dummy I2C clients using i2c_new_dummy() > function. It seems better way. As of now, all we need for HDMI DDC is i2c_adapter (including i2c phy), not i2c_client. > > There is quite strong rationale for this: > - DDC is always accessible on fixed addresses described in HDMI specification. > - HDMIPHY (including I2C address) is a part of HDMI IP and it is bound to > specific version of Exynos SoC > - no need to add virtual nodes in DTS You mean hdmiddc and hdmiphy nodes? If so, I think they are real nodes, not virtual nodes. Otherwise, plz give me more comments. Thanks, Inki Dae > - NVIDIA already use bindings to DDC bus instead of DDC client. Take a look to > arch/arm/boot/dts/tegra*.dts > > Regards, > Tomasz Stanislawski > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update
On Wed, Feb 19, 2014 at 09:08:39AM +, Lin, Mengdong wrote: > > -Original Message- > > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com] > > Sent: Tuesday, February 18, 2014 10:23 PM > > To: Lin, Mengdong > > Cc: Daniel Vetter; Takashi Iwai; alsa-devel at alsa-project.org; Barnes, > > Jesse; > > Zanoni, Paulo R; dri-devel; intel-gfx at lists.freedesktop.org > > Subject: Re: [Intel-gfx] Need your advice: Add a new communication > > inteface between HD-Audio and Gfx drivers for hotplug notification/ELD > > update > > > > On Tue, Feb 18, 2014 at 01:58:22PM +, Lin, Mengdong wrote: > > > Sorry to pick up this thread after a long time. > > > > > > > -Original Message- > > > > From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On > > > > Behalf Of Daniel Vetter > > > > Sent: Thursday, January 23, 2014 4:27 PM > > > > To: Takashi Iwai > > > > > > > On Thu, Jan 23, 2014 at 8:57 AM, Takashi Iwai wrote: > > > > >> Thanks for clarification! > > > > >> Maybe we can add output info (eg. display port number) to the eld > > > > >> entries > > > > under /proc/asound/cardx. Is it okay? > > > > > > > > > > It's possible, but the proc file is just a help. It can't be the API. > > > > > For accessing the information, we'll need some new API, or let > > > > > inform via sysfs of the new device. > > > > > > > > Links in sysfs sound like the best approach. drm already has nodes > > > > for each connector, so on the gfx side there's a natural endpoint > > already. > > > > sysfs links also avoids any naming issues from the start, e.g. the > > > > above DP connector id might lead to clashes with multiple cards. > > > > > > Hi Daniel, > > > > > > Is there a 1:1 mapping between these connector nodes and ports of Gfx > > display engine? > > > Eg. For Haswell Ultrabook, under > > > /sys/devices/pci:00/:00:02.0/drm/card0/ > > > There are four connector nodes, > > > card0-DP-1-> DDI port B > > > card0-eDP-1/ -> DDI port A > > > card0-HDMI-A-1/ -> DDI Port C > > > card0-HDMI-A-2/ -> Which DDI port ? Haswell-ULT does not > > support port D, and I think port E is for VGA. > > > > There's no fixed mapping with the port and the connector name. The > > number in the connector name is basically just a running number per > > connector type. However I do believe we do register the connectors in the > > order of the ports more or less always, so you can > > *sometimes* deduce the port name from the connector. > > > > I suppose in this example HDMI-A-1 is port B, HDMI-A-2 is port C, and > > DP-1 can be either port B or port C. DP++ is the reason why we have > > overlapping DP and HDMI connectors for the same port. > > Thanks for clarification, Ville! > > Does Haswell support DP++ on port B/C/D? Yes. > And will the name of these connector node change after system boot, e.g. > after S3/S4 cycles or hot-plug? The connector names can't change, except if you unload+reload the driver. But I suppose DP MST might change this. Or maybe we'll just expose three new fixed DP connectors per DDI port. One for each potential stream. > > > As long as the connector name is constant, it can help to find out the screen > status no matter the port works in HDMI or DP mode. > > There is 1:1 mapping between audio output pins and DDI ports. So I guess we need to expose the port->connector mapping somehow to the audio driver. How does this work with DP MST? On the display side the audio stuff happens in the transcoder, not the DDI port, AFAICS. For DP MST each transcoder can provide a single stream. > And the new ALSA PCM 'screen' control for a pin can reflect the connector > name in right mode. E.g. for pin/port B, it can return HDMI-A-1 or DP-1 > depending on what kind of monitor is connected. > > Thanks > Mengdong > > > > > > > Hi Takashi, > > > > > > To make user space figure out which audio output is connected to which > > screen (connector), maybe we can define a new ALSA control for each > > HDMI/DP PCM device: > > > e.g. numid=x,iface=PCM,name='Screen',device=3 > > > Reading the control will return the name of the DRM connector nodes > > like ' card0-DP-1'. The audio driver can get the connector name from the > > gfx driver. > > > > > > For DP1.2 Multi-stream transport, it's not supported by i915 and HD-A > > driver now. But probably there will be sub-nodes for the DP connector > > node in the future and an index in their name can be used distinguish > > monitors connected to the same DP port, like card0-DP-1.1, card0-DP-1.2, > > card0-DP-1.3 ... These names can be used by the above ALSA PCM 'Screen' > > control, so we can still know which audio output is to which monitor. > > > > > > Thanks > > > Mengdong > > > > > > ___ > > > Intel-gfx mailing list > > > Intel-gfx at lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Ville Syrj?l? > > Intel OTC -- Ville S
[PATCH v4 14/34] drm/exynos: hdmi: remove the i2c drivers and use devtree
2014-01-31 6:19 GMT+09:00 Sean Paul : > From: Daniel Kurtz > > The i2c client was previously being passed into the hdmi driver via a > dedicated i2c driver, and then a global variable. This patch removes all > of that and just uses the device tree to get the i2c_client. This patch > also properly references the client so we don't lose it before we're > done with it. > > Signed-off-by: Daniel Kurtz > [seanpaul changed to phandle lookup instead of using of node name] > Signed-off-by: Sean Paul > --- > > Changes in v2: > - Change include to linux/i2c.h instead of linux/of_i2c.h > Changes in v3: None > Changes in v4: > - Changed to find phy via phandle instead of by name > > .../devicetree/bindings/video/exynos_hdmi.txt | 5 ++ > drivers/gpu/drm/exynos/Makefile| 1 - > drivers/gpu/drm/exynos/exynos_ddc.c| 63 - > drivers/gpu/drm/exynos/exynos_hdmi.c | 59 +--- > drivers/gpu/drm/exynos/exynos_hdmi.h | 23 > drivers/gpu/drm/exynos/exynos_hdmiphy.c| 65 > -- > 6 files changed, 32 insertions(+), 184 deletions(-) > delete mode 100644 drivers/gpu/drm/exynos/exynos_ddc.c > delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmi.h > delete mode 100644 drivers/gpu/drm/exynos/exynos_hdmiphy.c > > diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt > b/Documentation/devicetree/bindings/video/exynos_hdmi.txt > index 50decf8..f9187a2 100644 > --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt > +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt > @@ -25,6 +25,9 @@ Required properties: > sclk_pixel. > - clock-names: aliases as per driver requirements for above clock IDs: > "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". > +- ddc: phandle to the hdmi ddc node > +- phy: phandle to the hdmi phy node > + > Example: > > hdmi { > @@ -32,4 +35,6 @@ Example: > reg = <0x1453 0x10>; > interrupts = <0 95 0>; > hpd-gpio = <&gpx3 7 1>; > + ddc = <&hdmi_ddc_node>; > + phy = <&hdmi_phy_node>; > }; > diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile > index 639b49e..819961a 100644 > --- a/drivers/gpu/drm/exynos/Makefile > +++ b/drivers/gpu/drm/exynos/Makefile > @@ -12,7 +12,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o > exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o > exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o > exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \ > - exynos_ddc.o exynos_hdmiphy.o \ >exynos_drm_hdmi.o > exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)+= exynos_drm_vidi.o > exynosdrm-$(CONFIG_DRM_EXYNOS_G2D) += exynos_drm_g2d.o > diff --git a/drivers/gpu/drm/exynos/exynos_ddc.c > b/drivers/gpu/drm/exynos/exynos_ddc.c > deleted file mode 100644 > index 6a8c84e..000 > --- a/drivers/gpu/drm/exynos/exynos_ddc.c > +++ /dev/null > @@ -1,63 +0,0 @@ > -/* > - * Copyright (C) 2011 Samsung Electronics Co.Ltd > - * Authors: > - * Seung-Woo Kim > - * Inki Dae > - * > - * This program is free software; you can redistribute it and/or modify it > - * under the terms of the GNU General Public License as published by the > - * Free Software Foundation; either version 2 of the License, or (at your > - * option) any later version. > - * > - */ > - > -#include > - > -#include > -#include > -#include > - > -#include "exynos_drm_drv.h" > -#include "exynos_hdmi.h" > - > -static int s5p_ddc_probe(struct i2c_client *client, > - const struct i2c_device_id *dev_id) > -{ > - hdmi_attach_ddc_client(client); > - > - dev_info(&client->adapter->dev, > - "attached %s into i2c adapter successfully\n", > - client->name); > - > - return 0; > -} > - > -static int s5p_ddc_remove(struct i2c_client *client) > -{ > - dev_info(&client->adapter->dev, > - "detached %s from i2c adapter successfully\n", > - client->name); > - > - return 0; > -} > - > -static struct of_device_id hdmiddc_match_types[] = { > - { > - .compatible = "samsung,exynos5-hdmiddc", > - }, { > - .compatible = "samsung,exynos4210-hdmiddc", > - }, { > - /* end node */ > - } > -}; > - > -struct i2c_driver ddc_driver = { > - .driver = { > - .name = "exynos-hdmiddc", > - .owner = THIS_MODULE, > - .of_match_table = hdmiddc_match_types, > - }, > - .probe = s5p_ddc_probe, > - .remove = s5p_ddc_remove, > - .command= NULL, > -}; > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gp
[Bug 74973] [radeonsi] Gimp OpenCL does not work
https://bugs.freedesktop.org/show_bug.cgi?id=74973 --- Comment #2 from darkbasic --- Created attachment 94348 --> https://bugs.freedesktop.org/attachment.cgi?id=94348&action=edit dump I noticed it suddently started working flawlessly so I asked myself what fixed it: patches from https://bugs.freedesktop.org/show_bug.cgi?id=72785 did fix it. I currently apply: 0001-SelectionDAG-Factor-ISD-MUL-lowering-code-out-of-DAG.patch 0002-SelectionDAG-Use-helper-function-to-improve-legaliza.patch 0001-R600-SI-Custom-select-64-bit-ADD.patch Beware that I modified "UP.Threshold = 500" to "UP.Threshold = 100" because "bfgminer --scrypt" didn't work otherwise. I attached dump from R600_DEBUG=cs GEGL_USE_OPENCL=yes gimp without the patches. -- 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/20140219/b0612844/attachment-0001.html>
[Bug 74973] [radeonsi] Gimp OpenCL does not work
https://bugs.freedesktop.org/show_bug.cgi?id=74973 --- Comment #3 from darkbasic --- Sorry I forgot one patch: https://bugs.freedesktop.org/attachment.cgi?id=94078 This is the one with "UP.Threshold = 100" instead of "UP.Threshold = 500" -- 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/20140219/a4d589ba/attachment.html>
[PATCH 2/6] seqno-fence: Hardware dma-buf implementation of fencing (v4)
op 17-02-14 19:41, Christian K?nig schreef: > Am 17.02.2014 19:24, schrieb Rob Clark: >> On Mon, Feb 17, 2014 at 12:36 PM, Christian K?nig >> wrote: >>> Am 17.02.2014 18:27, schrieb Rob Clark: >>> On Mon, Feb 17, 2014 at 11:56 AM, Christian K?nig wrote: > Am 17.02.2014 16:56, schrieb Maarten Lankhorst: > >> This type of fence can be used with hardware synchronization for simple >> hardware that can block execution until the condition >> (dma_buf[offset] - value) >= 0 has been met. > > Can't we make that just "dma_buf[offset] != 0" instead? As far as I know > this way it would match the definition M$ uses in their WDDM > specification > and so make it much more likely that hardware supports it. well 'buf[offset] >= value' at least means the same slot can be used for multiple operations (with increasing values of 'value').. not sure if that is something people care about. > =value seems to be possible with adreno and radeon. I'm not really sure > about others (although I presume it as least supported for nv desktop > stuff). For hw that cannot do >=value, we can either have a different > fence > implementation which uses the !=0 approach. Or change seqno-fence > implementation later if needed. But if someone has hw that can do !=0 but > not >=value, speak up now ;-) >>> >>> Here! Radeon can only do >=value on the DMA and 3D engine, but not with UVD >>> or VCE. And for the 3D engine it means draining the pipe, which isn't really >>> a good idea. >> hmm, ok.. forgot you have a few extra rings compared to me. Is UVD >> re-ordering from decode-order to display-order for you in hw? If not, >> I guess you need sw intervention anyways when a frame is done for >> frame re-ordering, so maybe hw->hw sync doesn't really matter as much >> as compared to gpu/3d->display. For dma<->3d interactions, seems like >> you would care more about hw<->hw sync, but I guess you aren't likely >> to use GPU A to do a resolve blit for GPU B.. > > No UVD isn't reordering, but since frame reordering is predictable you > usually end up with pipelining everything to the hardware. E.g. you send the > decode commands in decode order to the UVD block and if you have overlay > active one of the frames are going to be the first to display and then you > want to wait for it on the display side. > >> For 3D ring, I assume you probably want a CP_WAIT_FOR_IDLE before a >> CP_MEM_WRITE to update fence value in memory (for the one signalling >> the fence). But why would you need that before a CP_WAIT_REG_MEM (for >> the one waiting for the fence)? I don't exactly have documentation >> for adreno version of CP_WAIT_REG_{MEM,EQ,GTE}.. but PFP and ME >> appear to be same instruction set as r600, so I'm pretty sure they >> should have similar capabilities.. CP_WAIT_REG_MEM appears to be same >> but with 32bit gpu addresses vs 64b. > > You shouldn't use any of the CP commands for engine synchronization (neither > for wait nor for signal). The PFP and ME are just the top of a quite deep > pipeline and when you use any of the CP_WAIT functions you block them for > something and that's draining the pipeline. > > With the semaphore and fence commands the values are just attached as > prerequisite to the draw command, e.g. the CP setups the draw environment and > issues the command, but the actual execution of it is delayed until the "!= > 0" condition hits. And in the meantime the CP already prepares the next draw > operation. > > But at least for compute queues wait semaphore aren't the perfect solution > either. What you need then is a GPU scheduler that uses a kernel task for > setting up the command submission for you when all prerequisites are meet. nouveau has sort of a scheduler in hardware. It can yield when waiting on a semaphore. And each process gets their own context and the timeslices can be adjusted. ;-) But I don't mind changing this patch when an actual user pops up. Nouveau can do a wait for (*sema & mask) != 0 only on nvc0 and newer, where mask can be chosen. But it can do == somevalue and >= somevalue on older relevant optimus hardware, so if we know that it was zero before and we know the sign of the new value that could work too. Adding ops and a separate mask later on when users pop up is fine with me, the original design here was chosen so I could map the intel status page read-only into the process specific nvidia vm. ~Maarten
[PATCH 1/2] drm: Make control nodes master-less
Like for render-nodes, there is no point in maintaining the master concept for control nodes, so set the struct drm_file::master pointer to NULL. At the same time, make sure DRM_MASTER | DRM_CONTROL_ALLOW ioctls are always allowed when called through the control node. Previously the caller also needed to be master. Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/drm_drv.c |5 +++-- drivers/gpu/drm/drm_fops.c |5 +++-- include/drm/drmP.h |5 + 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index 345be03..42af8bd 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/drm/drm_drv.c @@ -355,8 +355,9 @@ long drm_ioctl(struct file *filp, retcode = -EINVAL; } else if (((ioctl->flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN)) || ((ioctl->flags & DRM_AUTH) && !drm_is_render_client(file_priv) && !file_priv->authenticated) || - ((ioctl->flags & DRM_MASTER) && !file_priv->is_master) || - (!(ioctl->flags & DRM_CONTROL_ALLOW) && (file_priv->minor->type == DRM_MINOR_CONTROL)) || + (((ioctl->flags & DRM_MASTER) && !file_priv->is_master) && + !(drm_is_control(file_priv) && (ioctl->flags & DRM_CONTROL_ALLOW))) || + (!(ioctl->flags & DRM_CONTROL_ALLOW) && drm_is_control(file_priv)) || (!(ioctl->flags & DRM_RENDER_ALLOW) && drm_is_render_client(file_priv))) { retcode = -EACCES; } else { diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 7f2af9a..08a3196 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -259,7 +259,8 @@ static int drm_open_helper(struct inode *inode, struct file *filp, /* if there is no current master make this fd it, but do not create * any master object for render clients */ mutex_lock(&dev->struct_mutex); - if (!priv->minor->master && !drm_is_render_client(priv)) { + if (!priv->minor->master && !drm_is_render_client(priv) && + !drm_is_control(priv)) { /* create a new master */ priv->minor->master = drm_master_create(priv->minor); if (!priv->minor->master) { @@ -297,7 +298,7 @@ static int drm_open_helper(struct inode *inode, struct file *filp, goto out_close; } } - } else if (!drm_is_render_client(priv)) { + } else if (!drm_is_render_client(priv) && !drm_is_control(priv)) { /* get a reference to the master */ priv->master = drm_master_get(priv->minor->master); } diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 04a7f31..ff68e26 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1246,6 +1246,11 @@ static inline bool drm_is_render_client(struct drm_file *file_priv) return file_priv->minor->type == DRM_MINOR_RENDER; } +static inline bool drm_is_control(struct drm_file *file_priv) +{ + return file_priv->minor->type == DRM_MINOR_CONTROL; +} + /**/ /** \name Internal function definitions */ /*@{*/ -- 1.7.10.4
[PATCH 2/2] drm: Remove the minor master list
It doesn't appear to be used anywhere. Signed-off-by: Thomas Hellstrom --- drivers/gpu/drm/drm_stub.c |5 - include/drm/drmP.h |2 -- 2 files changed, 7 deletions(-) diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c index 98a33c580..4f17c79 100644 --- a/drivers/gpu/drm/drm_stub.c +++ b/drivers/gpu/drm/drm_stub.c @@ -152,8 +152,6 @@ struct drm_master *drm_master_create(struct drm_minor *minor) INIT_LIST_HEAD(&master->magicfree); master->minor = minor; - list_add_tail(&master->head, &minor->master_list); - return master; } @@ -171,8 +169,6 @@ static void drm_master_destroy(struct kref *kref) struct drm_device *dev = master->minor->dev; struct drm_map_list *r_list, *list_temp; - list_del(&master->head); - if (dev->driver->master_destroy) dev->driver->master_destroy(dev, master); @@ -296,7 +292,6 @@ static int drm_get_minor(struct drm_device *dev, struct drm_minor **minor, new_minor->device = MKDEV(DRM_MAJOR, minor_id); new_minor->dev = dev; new_minor->index = minor_id; - INIT_LIST_HEAD(&new_minor->master_list); idr_replace(&drm_minors_idr, new_minor, minor_id); diff --git a/include/drm/drmP.h b/include/drm/drmP.h index ff68e26..56c519f 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -718,7 +718,6 @@ struct drm_master { struct kref refcount; /* refcount for this master */ - struct list_head head; /**< each minor contains a list of masters */ struct drm_minor *minor; /**< link back to minor we are a master for */ char *unique; /**< Unique identifier: e.g., busid */ @@ -1050,7 +1049,6 @@ struct drm_minor { struct mutex debugfs_lock; /* Protects debugfs_list. */ struct drm_master *master; /* currently active master for this node */ - struct list_head master_list; struct drm_mode_group mode_group; }; -- 1.7.10.4
[PATCH 4/6] android: convert sync to fence api, v4
On 02/17/2014 04:57 PM, Maarten Lankhorst wrote: > Android syncpoints can be mapped to a timeline. This removes the need > to maintain a separate api for synchronization. I've left the android > trace events in place, but the core fence events should already be > sufficient for debugging. > > v2: > - Call fence_remove_callback in sync_fence_free if not all fences have fired. > v3: > - Merge Colin Cross' bugfixes, and the android fence merge optimization. > v4: > - Merge with the upstream fixes. > > Signed-off-by: Maarten Lankhorst > --- > drivers/staging/android/Kconfig |1 > drivers/staging/android/Makefile |2 > drivers/staging/android/sw_sync.c|4 > drivers/staging/android/sync.c | 892 > +++--- > drivers/staging/android/sync.h | 80 ++- > drivers/staging/android/sync_debug.c | 245 + > drivers/staging/android/trace/sync.h | 12 > 7 files changed, 592 insertions(+), 644 deletions(-) > create mode 100644 drivers/staging/android/sync_debug.c > > diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig > index b91c758883bf..ecc8194242b5 100644 > --- a/drivers/staging/android/Kconfig > +++ b/drivers/staging/android/Kconfig > @@ -77,6 +77,7 @@ config SYNC > bool "Synchronization framework" > default n > select ANON_INODES > + select DMA_SHARED_BUFFER > ---help--- > This option enables the framework for synchronization between multiple > drivers. Sync implementations can take advantage of hardware > diff --git a/drivers/staging/android/Makefile > b/drivers/staging/android/Makefile > index 0a01e1914905..517ad5ffa429 100644 > --- a/drivers/staging/android/Makefile > +++ b/drivers/staging/android/Makefile > @@ -9,5 +9,5 @@ obj-$(CONFIG_ANDROID_TIMED_OUTPUT)+= timed_output.o > obj-$(CONFIG_ANDROID_TIMED_GPIO) += timed_gpio.o > obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER) += lowmemorykiller.o > obj-$(CONFIG_ANDROID_INTF_ALARM_DEV) += alarm-dev.o > -obj-$(CONFIG_SYNC) += sync.o > +obj-$(CONFIG_SYNC) += sync.o sync_debug.o > obj-$(CONFIG_SW_SYNC)+= sw_sync.o > diff --git a/drivers/staging/android/sw_sync.c > b/drivers/staging/android/sw_sync.c > index f24493ac65e3..a76db3ff87cb 100644 > --- a/drivers/staging/android/sw_sync.c > +++ b/drivers/staging/android/sw_sync.c > @@ -50,7 +50,7 @@ static struct sync_pt *sw_sync_pt_dup(struct sync_pt > *sync_pt) > { > struct sw_sync_pt *pt = (struct sw_sync_pt *) sync_pt; > struct sw_sync_timeline *obj = > - (struct sw_sync_timeline *)sync_pt->parent; > + (struct sw_sync_timeline *)sync_pt_parent(sync_pt); > > return (struct sync_pt *) sw_sync_pt_create(obj, pt->value); > } > @@ -59,7 +59,7 @@ static int sw_sync_pt_has_signaled(struct sync_pt *sync_pt) > { > struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt; > struct sw_sync_timeline *obj = > - (struct sw_sync_timeline *)sync_pt->parent; > + (struct sw_sync_timeline *)sync_pt_parent(sync_pt); > > return sw_sync_cmp(obj->value, pt->value) >= 0; > } > diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c > index 3d05f662110b..8e77cd73b739 100644 > --- a/drivers/staging/android/sync.c > +++ b/drivers/staging/android/sync.c > @@ -31,22 +31,13 @@ > #define CREATE_TRACE_POINTS > #include "trace/sync.h" > > -static void sync_fence_signal_pt(struct sync_pt *pt); > -static int _sync_pt_has_signaled(struct sync_pt *pt); > -static void sync_fence_free(struct kref *kref); > -static void sync_dump(void); > - > -static LIST_HEAD(sync_timeline_list_head); > -static DEFINE_SPINLOCK(sync_timeline_list_lock); > - > -static LIST_HEAD(sync_fence_list_head); > -static DEFINE_SPINLOCK(sync_fence_list_lock); > +static const struct fence_ops android_fence_ops; > +static const struct file_operations sync_fence_fops; > > struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops > *ops, > int size, const char *name) > { > struct sync_timeline *obj; > - unsigned long flags; > > if (size < sizeof(struct sync_timeline)) > return NULL; > @@ -57,17 +48,14 @@ struct sync_timeline *sync_timeline_create(const struct > sync_timeline_ops *ops, > > kref_init(&obj->kref); > obj->ops = ops; > + obj->context = fence_context_alloc(1); > strlcpy(obj->name, name, sizeof(obj->name)); > > INIT_LIST_HEAD(&obj->child_list_head); > - spin_lock_init(&obj->child_list_lock); > - > INIT_LIST_HEAD(&obj->active_list_head); > - spin_lock_init(&obj->active_list_lock); > + spin_lock_init(&obj->child_list_lock); > > - spin_lock_irqsave(&sync_timeline_list_lock, flags); > - list_add_tail(&obj->sync_timeline_list, &sync_timeline_list_head); > - spin_unlock_irqrestore(&sync_timeline_list_
[PATCH 3/6] dma-buf: use reservation objects
On 02/17/2014 04:56 PM, Maarten Lankhorst wrote: > This allows reservation objects to be used in dma-buf. it's required > for implementing polling support on the fences that belong to a dma-buf. > > Signed-off-by: Maarten Lankhorst > Acked-by: Mauro Carvalho Chehab > #drivers/media/v4l2-core/ For the TTM part: Acked-by: Thomas Hellstrom
XFX r7-250a-lzh4 not displaying 3840x2160 @ 30Hz over HDMI
On Tue, Feb 18, 2014 at 5:28 AM, Adam Richter wrote: > The XFX Radeon r7-240a-clh4 and XFX Radeon r7-250a-zlh4 video cards do not > seem to be able to generate 3840x2160 @ 30 Hz video modes over HDMI, even > though I believe their hardware is supposed to be capable of this (~299 MHz > pixel clock). > > At least with my se39uy04 39" Seiki television, the Radeon X.org driver > happily passed through the five 3840x2160 @ 24-30 Hz that the television's > advertises in its EDID modes to xrandr, meaning that driver thinks it can > support those video modes, but, if I select any of them, the telvision just > says "mode not support." In comparison, if I make a custom video mode for > 3840x2160 @ 15Hz, the 4k TV displays that fine. > Please file a bug (https://bugs.freedesktop.org, product DRI, component DRM/Radeon) and attach your dmesg output and xorg log. > I observed this problem with the r7-240 and r7-250 on Linux 3.13.0-x86_64, > and with the r7-250 on Linux-3.14-rc3-x86_64 (I haven't tried the r7-240 on > it). > > > I am reporting this bug now primarily in the hopes that doing so might > eventually benefit other users. As for my own use, it looks like I'm > probably not going to use either of these video cards anyhow, because they > appear not to support dual link, contrary to Tiger Direct's description fo > the r7-250 card, by the way (yes, I tried faking dual link connector > information in atombios.c). That said, I am happy to do further experiments > with these cards if that would be helpful. > They support duallink DVI just fine assuming the oem has wired them up such that they can be used. Oland chips (R7 240, R7 250) only have 2 digital links so if you want duallink DVI, both would have to be used for DVI which not leave any links for other connectors. If you board has more than one digital connector, it's probably single link. Most other SI and CI chips support 6 digital links. Alex
[Bug 70741] Oops at radeon module (Radeon HD2400 at laptop Asus A8SR)
https://bugzilla.kernel.org/show_bug.cgi?id=70741 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(Other)|Video(DRI - non Intel) Assignee|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75211] New: radeonsi/llvm SIGABRT in Antichamber (UDK)
https://bugs.freedesktop.org/show_bug.cgi?id=75211 Priority: medium Bug ID: 75211 Assignee: dri-devel at lists.freedesktop.org Summary: radeonsi/llvm SIGABRT in Antichamber (UDK) Severity: normal Classification: Unclassified OS: All Reporter: haagch.christoph at googlemail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 94363 --> https://bugs.freedesktop.org/attachment.cgi?id=94363&action=edit backtrace without debug symbols HD 7970M, mesa recent git, llvm 3.5 recent svn. Antichamber based on Unreal Engine is available in the latest Humble Bundle. The crash doesn't seem to happen deterministically, I produced such a crash two times now by playing the game for a few minutes and then it randomly crashed. UDKGame-Linux: /build/lib32-llvm-svn/src/llvm/include/llvm/CodeGen/SlotIndexes.h:417: llvm::SlotIndex llvm::SlotIndexes::getInstructionIndex(const llvm::MachineInstr*) const: Assertion `itr != mi2iMap.end() && "Instruction not found in maps."' failed. Program received signal SIGABRT, Aborted. 0xf7fdb430 in __kernel_vsyscall () The backtrace I attached is without debug symbols so maybe isn't too informative. Later I will compile with debug symbols and provide a better one if needed. -- 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/20140219/90948a1c/attachment.html>
[PATCH libdrm] Mark functions printf-like where possible
From: Thierry Reding These functions all take a format string and either a list of variable arguments or a va_list. Use the new DRM_PRINTFLIKE macro to tell the compiler about it so that the arguments can be checked against the format string. Signed-off-by: Thierry Reding --- intel/intel_decode.c | 7 ++- tests/drmstat.c | 2 +- xf86drm.c| 10 +++--- xf86drm.h| 2 +- 4 files changed, 11 insertions(+), 10 deletions(-) diff --git a/intel/intel_decode.c b/intel/intel_decode.c index c0a0cafc904e..61239dd96d27 100644 --- a/intel/intel_decode.c +++ b/intel/intel_decode.c @@ -29,6 +29,7 @@ #include #include +#include "xf86drm.h" #include "intel_chipset.h" #include "intel_bufmgr.h" @@ -104,11 +105,7 @@ static float int_as_float(uint32_t intval) return uval.f; } -static void -instr_out(struct drm_intel_decode *ctx, unsigned int index, - const char *fmt, ...) __attribute__((format(__printf__, 3, 4))); - -static void +static void DRM_PRINTFLIKE(3, 4) instr_out(struct drm_intel_decode *ctx, unsigned int index, const char *fmt, ...) { diff --git a/tests/drmstat.c b/tests/drmstat.c index 345b8d2cda31..c51cbc6c9f61 100644 --- a/tests/drmstat.c +++ b/tests/drmstat.c @@ -425,7 +425,7 @@ int main(int argc, char **argv) return r; } -void +void DRM_PRINTFLIKE(4, 0) xf86VDrvMsgVerb(int scrnIndex, int type, int verb, const char *format, va_list args) { diff --git a/xf86drm.c b/xf86drm.c index 720952ff2cbd..fa5701abae51 100644 --- a/xf86drm.c +++ b/xf86drm.c @@ -104,12 +104,16 @@ void drmSetServerInfo(drmServerInfoPtr info) * This function is a wrapper around vfprintf(). */ -static int drmDebugPrint(const char *format, va_list ap) +static int DRM_PRINTFLIKE(1, 0) +drmDebugPrint(const char *format, va_list ap) { return vfprintf(stderr, format, ap); } -static int (*drm_debug_print)(const char *format, va_list ap) = drmDebugPrint; +typedef int DRM_PRINTFLIKE(1, 0) (*debug_msg_func_t)(const char *format, +va_list ap); + +static debug_msg_func_t drm_debug_print = drmDebugPrint; void drmMsg(const char *format, ...) @@ -129,7 +133,7 @@ drmMsg(const char *format, ...) } void -drmSetDebugMsgFunction(int (*debug_msg_ptr)(const char *format, va_list ap)) +drmSetDebugMsgFunction(debug_msg_func_t debug_msg_ptr) { drm_debug_print = debug_msg_ptr; } diff --git a/xf86drm.h b/xf86drm.h index 5e170f86fe5e..c024cc446354 100644 --- a/xf86drm.h +++ b/xf86drm.h @@ -704,7 +704,7 @@ extern int drmSLLookupNeighbors(void *l, unsigned long key, extern int drmOpenOnce(void *unused, const char *BusID, int *newlyopened); extern void drmCloseOnce(int fd); -extern void drmMsg(const char *format, ...); +extern void drmMsg(const char *format, ...) DRM_PRINTFLIKE(1, 2); extern int drmSetMaster(int fd); extern int drmDropMaster(int fd); -- 1.8.4.2
[PATCH libdrm] tests: Use drmFreeVersion() instead of drmFree()
From: Thierry Reding drmFreeVersion() frees the memory allocated for the name, date and desc fields in addition to that for the struct _drmVersion. Signed-off-by: Thierry Reding --- tests/getversion.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/getversion.c b/tests/getversion.c index 53d1d354ea16..bcec46999140 100644 --- a/tests/getversion.c +++ b/tests/getversion.c @@ -43,7 +43,7 @@ int main(int argc, char **argv) assert(strlen(v->desc) != 0); if (strcmp(v->name, "i915") == 0) assert(v->version_major >= 1); - drmFree(v); + drmFreeVersion(v); close(fd); return 0; } -- 1.8.4.2
[RFC libdrm 0/6] Add NVIDIA Tegra support
From: Thierry Reding Hi, This series adds libdrm-tegra with a very lightweight API on top of the kernel interfaces. Most of the functions provided here have been in use in various driver efforts in different incarnations. This is an attempt to consolidate, so I'm looking for review comments especially by Erik to ensure it can be used by grate. I've used these to implement basic EXA support in xf86-video-opentegra, which I've pushed to a repository here[0]. The libdrm patches are also available in a repository[1] for convenience. Patch 1 adds support for symbol visibility if GCC supports it. This is used by later patches to make only the public symbols visible in the libdrm-tegra shared object. Patch 2 adds support for managing a Tegra DRM object (which doesn't do a whole lot more than wrap a file descriptor) and buffer objects. A small test program is added in patch 3 to check that a Tegra DRM object can be created on top of a DRM device. Patch 4 adds functions to open a channel to an engine (gr2d or gr3d), create and manage a job as well as compose command streams in a push buffer and wait for a fence. To make it easier to write further tests, patch 5 introduces some DRM helpers to setup a screen and attach framebuffers to it. A very basic interface is also provided for the gr2d unit, which can be used to do a solid rectangle fill. Finally patch 6 uses the helpers introduced in patch 5 to fill a sub- region of the screen with a solid color. Thierry [0]: http://cgit.freedesktop.org/~tagr/xf86-video-opentegra/ [1]: http://cgit.freedesktop.org/~tagr/drm/ Thierry Reding (6): configure: Support symbol visibility when available libdrm: Add NVIDIA Tegra support tegra: Add simple test for drm_tegra_open() tegra: Add channel, job, pushbuf and fence APIs tegra: Add helper library for tests tegra: Add gr2d-fill test Makefile.am | 6 +- configure.ac | 36 +- include/drm/Makefile.am | 1 + include/drm/tegra_drm.h | 157 ++ tegra/Makefile.am| 24 tegra/channel.c | 127 + tegra/fence.c| 72 tegra/job.c | 167 +++ tegra/libdrm_tegra.pc.in | 11 ++ tegra/private.h | 117 +++ tegra/pushbuf.c | 137 +++ tegra/tegra.c| 253 + tegra/tegra.h| 99 tests/Makefile.am| 4 + tests/modetest/modetest.c| 2 +- tests/tegra/Makefile.am | 29 + tests/tegra/drm-test-tegra.c | 132 ++ tests/tegra/drm-test-tegra.h | 55 + tests/tegra/drm-test.c | 261 +++ tests/tegra/drm-test.h | 73 tests/tegra/gr2d-fill.c | 145 tests/tegra/openclose.c | 63 +++ tests/vbltest/vbltest.c | 2 +- 23 files changed, 1969 insertions(+), 4 deletions(-) create mode 100644 include/drm/tegra_drm.h create mode 100644 tegra/Makefile.am create mode 100644 tegra/channel.c create mode 100644 tegra/fence.c create mode 100644 tegra/job.c create mode 100644 tegra/libdrm_tegra.pc.in create mode 100644 tegra/private.h create mode 100644 tegra/pushbuf.c create mode 100644 tegra/tegra.c create mode 100644 tegra/tegra.h create mode 100644 tests/tegra/Makefile.am create mode 100644 tests/tegra/drm-test-tegra.c create mode 100644 tests/tegra/drm-test-tegra.h create mode 100644 tests/tegra/drm-test.c create mode 100644 tests/tegra/drm-test.h create mode 100644 tests/tegra/gr2d-fill.c create mode 100644 tests/tegra/openclose.c -- 1.8.4.2
[RFC libdrm 1/6] configure: Support symbol visibility when available
From: Thierry Reding Checks whether or not the compiler supports the -fvisibility option. If so it sets the VISIBILITY_CFLAGS variable which can be added to the per directory AM_CFLAGS where appropriate. Libraries can use the HAVE_VISIBILITY preprocessor definition to check for availability and use something like this: #if defined(HAVE_VISIBILITY) # define drm_private __attribute__((visibility("hidden"))) # define drm_public __attribute__((visibility("default"))) #else # define drm_private # define drm_public #endif By default all symbols will be hidden via the VISIBILITY_CFLAGS. Only symbols explicitly marked drm_public will be exported. Signed-off-by: Thierry Reding --- configure.ac | 20 1 file changed, 20 insertions(+) diff --git a/configure.ac b/configure.ac index d2d19d66dc17..3f4164238494 100644 --- a/configure.ac +++ b/configure.ac @@ -365,6 +365,26 @@ AC_ARG_WITH([kernel-source], [kernel_source="$with_kernel_source"]) AC_SUBST(kernel_source) +dnl Add flags for gcc and g++ +if test "x$GCC" = xyes; then +# Enable -fvisibility=hidden if using a gcc that supports it +save_CFLAGS="$CFLAGS" +AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden]) +VISIBILITY_CFLAGS="-fvisibility=hidden" +CFLAGS="$CFLAGS $VISIBILITY_CFLAGS" +AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), + [VISIBILITY_CFLAGS=""; AC_MSG_RESULT([no])]); + +# Restore CFLAGS; VISIBILITY_CFLAGS are added to it where needed. +CFLAGS=$save_CFLAGS + +if test "x$VISIBILITY_CFLAGS" != x; then +AC_DEFINE(HAVE_VISIBILITY, 1, [Compiler has -fvisibility support]) +fi + +AC_SUBST([VISIBILITY_CFLAGS]) +fi + AC_SUBST(WARN_CFLAGS) AC_CONFIG_FILES([ Makefile -- 1.8.4.2
[RFC libdrm 3/6] tegra: Add simple test for drm_tegra_open()
From: Thierry Reding This test opens a device, dumps the version information and checks that a Tegra DRM context can be opened on it. Signed-off-by: Thierry Reding --- configure.ac| 1 + tests/Makefile.am | 4 tests/tegra/Makefile.am | 20 tests/tegra/openclose.c | 63 + 4 files changed, 88 insertions(+) create mode 100644 tests/tegra/Makefile.am create mode 100644 tests/tegra/openclose.c diff --git a/configure.ac b/configure.ac index 752a70592933..c4ae14e8d2e1 100644 --- a/configure.ac +++ b/configure.ac @@ -421,6 +421,7 @@ AC_CONFIG_FILES([ tests/radeon/Makefile tests/vbltest/Makefile tests/exynos/Makefile + tests/tegra/Makefile include/Makefile include/drm/Makefile man/Makefile diff --git a/tests/Makefile.am b/tests/Makefile.am index cd1149130214..0a3d21f2d99f 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -24,6 +24,10 @@ if HAVE_EXYNOS SUBDIRS += exynos endif +if HAVE_TEGRA +SUBDIRS += tegra +endif + if HAVE_LIBUDEV check_LTLIBRARIES = libdrmtest.la diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am new file mode 100644 index ..7039f09d38aa --- /dev/null +++ b/tests/tegra/Makefile.am @@ -0,0 +1,20 @@ +AM_CPPFLAGS = \ + -I$(top_srcdir)/include/drm \ + -I$(top_srcdir)/tegra + +AM_CFLAGS = -Wall -Werror + +LDADD = \ + ../../tegra/libdrm_tegra.la + +TESTS = \ + openclose \ + +if HAVE_INSTALL_TESTS +testdir = $(libexecdir)/libdrm/tests/tegra +test_PROGRAMS = \ + $(TESTS) +else +noinst_PROGRAMS = $(TESTS) +check_PROGRAMS = $(TESTS) +endif diff --git a/tests/tegra/openclose.c b/tests/tegra/openclose.c new file mode 100644 index ..5b4230c774f6 --- /dev/null +++ b/tests/tegra/openclose.c @@ -0,0 +1,63 @@ +/* + * Copyright ? 2014 NVIDIA Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +#ifdef HAVE_CONFIG_H +# include "config.h" +#endif + +#include +#include +#include + +#include "xf86drm.h" +#include "tegra.h" + +int main(int argc, char *argv[]) +{ + struct drm_tegra *tegra; + drmVersionPtr version; + int err, fd; + + fd = open(argv[1], O_RDWR); + if (fd < 0) + return 1; + + version = drmGetVersion(fd); + if (version) { + printf("Version: %d.%d.%d\n", version->version_major, + version->version_minor, version->version_patchlevel); + printf(" Name: %s\n", version->name); + printf(" Date: %s\n", version->date); + printf(" Description: %s\n", version->desc); + + drmFreeVersion(version); + } + + err = drm_tegra_new(&tegra, fd); + if (err < 0) + return 1; + + drm_tegra_close(tegra); + close(fd); + + return 0; +} -- 1.8.4.2
[RFC libdrm 2/6] libdrm: Add NVIDIA Tegra support
From: Thierry Reding Add the libdrm_tegra helper library to encapsulate Tegra-specific interfaces to the DRM. Furthermore, Tegra is added to the list of supported chips in the modetest and vbltest programs. Signed-off-by: Thierry Reding Signed-off-by: Erik Faye-Lund Signed-off-by: Thierry Reding --- Makefile.am | 6 +- configure.ac | 15 ++- include/drm/Makefile.am | 1 + include/drm/tegra_drm.h | 157 tegra/Makefile.am | 20 tegra/libdrm_tegra.pc.in | 11 ++ tegra/private.h | 58 +++ tegra/tegra.c | 253 ++ tegra/tegra.h | 47 + tests/modetest/modetest.c | 2 +- tests/vbltest/vbltest.c | 2 +- 11 files changed, 568 insertions(+), 4 deletions(-) create mode 100644 include/drm/tegra_drm.h create mode 100644 tegra/Makefile.am create mode 100644 tegra/libdrm_tegra.pc.in create mode 100644 tegra/private.h create mode 100644 tegra/tegra.c create mode 100644 tegra/tegra.h diff --git a/Makefile.am b/Makefile.am index 826c30d0c0d9..14c402dce74f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -51,7 +51,11 @@ if HAVE_FREEDRENO FREEDRENO_SUBDIR = freedreno endif -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests include man +if HAVE_TEGRA +TEGRA_SUBDIR = tegra +endif + +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) $(TEGRA_SUBDIR) tests include man libdrm_la_LTLIBRARIES = libdrm.la libdrm_ladir = $(libdir) diff --git a/configure.ac b/configure.ac index 3f4164238494..752a70592933 100644 --- a/configure.ac +++ b/configure.ac @@ -98,6 +98,11 @@ AC_ARG_ENABLE(freedreno-experimental-api, [Enable support for freedreno's experimental API (default: disabled)]), [FREEDRENO=$enableval], [FREEDRENO=no]) +AC_ARG_ENABLE(tegra-experimental-api, + AS_HELP_STRING([--enable-tegra-experimental-api], + [Enable support for Tegra's experimental API (default: disabled)]), + [TEGRA=$enableval], [TEGRA=no]) + AC_ARG_ENABLE(install-test-programs, AS_HELP_STRING([--enable-install-test-programs], [Install test programs (default: no)]), @@ -218,6 +223,11 @@ if test "x$FREEDRENO" = xyes; then AC_DEFINE(HAVE_FREEDRENO, 1, [Have freedreno support]) fi +AM_CONDITIONAL(HAVE_TEGRA, [test "x$TEGRA" = xyes]) +if test "x$TEGRA" = xyes; then + AC_DEFINE(HAVE_TEGRA, 1, [Have Tegra support]) +fi + AM_CONDITIONAL(HAVE_INSTALL_TESTS, [test "x$INSTALL_TESTS" = xyes]) if test "x$INSTALL_TESTS" = xyes; then AC_DEFINE(HAVE_INSTALL_TESTS, 1, [Install test programs]) @@ -269,7 +279,7 @@ else fi AM_CONDITIONAL([HAVE_MANPAGES_STYLESHEET], [test "x$HAVE_MANPAGES_STYLESHEET" = "xyes"]) -if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o "x$OMAP" != "xno" -o "x$FREEDRENO" != "xno"; then +if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != "xno" -o "x$OMAP" != "xno" -o "x$FREEDRENO" != "xno" -o "x$TEGRA" != "xno"; then # Check for atomic intrinsics AC_CACHE_CHECK([for native atomic primitives], drm_cv_atomic_primitives, [ @@ -402,6 +412,8 @@ AC_CONFIG_FILES([ exynos/libdrm_exynos.pc freedreno/Makefile freedreno/libdrm_freedreno.pc + tegra/Makefile + tegra/libdrm_tegra.pc tests/Makefile tests/modeprint/Makefile tests/modetest/Makefile @@ -426,4 +438,5 @@ echo " Nouveau API$NOUVEAU" echo " OMAP API $OMAP" echo " EXYNOS API $EXYNOS" echo " Freedreno API $FREEDRENO" +echo " Tegra API $TEGRA" echo "" diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am index 2bc34d2ffd9f..f591abc45152 100644 --- a/include/drm/Makefile.am +++ b/include/drm/Makefile.am @@ -35,6 +35,7 @@ klibdrminclude_HEADERS = \ radeon_drm.h \ savage_drm.h \ sis_drm.h \ + tegra_drm.h \ via_drm.h \ mach64_drm.h \ qxl_drm.h diff --git a/include/drm/tegra_drm.h b/include/drm/tegra_drm.h new file mode 100644 index ..956ed8aa9d98 --- /dev/null +++ b/include/drm/tegra_drm.h @@ -0,0 +1,157 @@ +/* + * Copyright (c) 2012-2013, NVIDIA CORPORATION. All rights reserved. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the + * "Software"), to deal in the Software without restriction, including + * without limitation the rights to use, copy, modify, merge, publish, + * distribute, sub license, and/or sell copies of the Software, and to + * permit persons to whom the Software is furnished to do so, subject to + * the following conditions: + * + * The above copyright notice and this permission notice (includi
[RFC libdrm 4/6] tegra: Add channel, job, pushbuf and fence APIs
From: Thierry Reding These functions can be used to open channels to engines, manage job submissions, create push buffers to store command streams in and wait until jobs have been completed. Signed-off-by: Thierry Reding --- tegra/Makefile.am | 4 ++ tegra/channel.c | 127 + tegra/fence.c | 72 +++ tegra/job.c | 167 ++ tegra/private.h | 59 +++ tegra/pushbuf.c | 137 tegra/tegra.h | 52 + 7 files changed, 618 insertions(+) create mode 100644 tegra/channel.c create mode 100644 tegra/fence.c create mode 100644 tegra/job.c create mode 100644 tegra/pushbuf.c diff --git a/tegra/Makefile.am b/tegra/Makefile.am index 1b83145b120d..c73587e8661e 100644 --- a/tegra/Makefile.am +++ b/tegra/Makefile.am @@ -11,6 +11,10 @@ libdrm_tegra_la_LDFLAGS = -version-number 0:0:0 -no-undefined libdrm_tegra_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@ libdrm_tegra_la_SOURCES = \ + channel.c \ + fence.c \ + job.c \ + pushbuf.c \ tegra.c libdrm_tegraincludedir = ${includedir}/libdrm diff --git a/tegra/channel.c b/tegra/channel.c new file mode 100644 index ..03cce30e98b9 --- /dev/null +++ b/tegra/channel.c @@ -0,0 +1,127 @@ +/* + * Copyright ? 2012, 2013 Thierry Reding + * Copyright ? 2013 Erik Faye-Lund + * Copyright ? 2014 NVIDIA Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +#ifdef HAVE_CONFIG_H +# include "config.h" +#endif + +#include +#include + +#include "private.h" + +static int drm_tegra_channel_setup(struct drm_tegra_channel *channel) +{ + struct drm_tegra *drm = channel->drm; + struct drm_tegra_get_syncpt args; + int err; + + memset(&args, 0, sizeof(args)); + args.context = channel->context; + args.index = 0; + + err = ioctl(drm->fd, DRM_IOCTL_TEGRA_GET_SYNCPT, &args); + if (err < 0) + return -errno; + + channel->syncpt = args.id; + + return 0; +} + +drm_public +int drm_tegra_channel_open(struct drm_tegra_channel **channelp, + struct drm_tegra *drm, + enum drm_tegra_class client) +{ + struct drm_tegra_open_channel args; + struct drm_tegra_channel *channel; + enum host1x_class class; + int err; + + switch (client) { + case DRM_TEGRA_GR2D: + class = HOST1X_CLASS_GR2D; + break; + + case DRM_TEGRA_GR3D: + class = HOST1X_CLASS_GR3D; + break; + + default: + return -EINVAL; + } + + channel = calloc(1, sizeof(*channel)); + if (!channel) + return -ENOMEM; + + channel->drm = drm; + + memset(&args, 0, sizeof(args)); + args.client = class; + + err = ioctl(drm->fd, DRM_IOCTL_TEGRA_OPEN_CHANNEL, &args); + if (err < 0) { + free(channel); + return -errno; + } + + channel->context = args.context; + channel->class = class; + + err = drm_tegra_channel_setup(channel); + if (err < 0) { + free(channel); + return err; + } + + *channelp = channel; + + return 0; +} + +drm_public +int drm_tegra_channel_close(struct drm_tegra_channel *channel) +{ + struct drm_tegra_open_channel args; + struct drm_tegra *drm; + int err; + + if (!channel) + return -EINVAL; + + drm = channel->drm; + + memset(&args, 0, sizeof(args)); + args.context = channel->context; + + err = ioctl(drm->fd, DRM_IOCTL_TEGRA_CLOSE_CHANNEL, &args); + if (err < 0) + return -errno; + + free(channel); + + return 0; +} diff --git a/tegra/fence.c b/tegra/fence.c new file mode 10
[RFC libdrm 5/6] tegra: Add helper library for tests
From: Thierry Reding This library provides helpers for common functionality needed by test programs. Signed-off-by: Thierry Reding --- tests/tegra/Makefile.am | 10 +- tests/tegra/drm-test-tegra.c | 132 ++ tests/tegra/drm-test-tegra.h | 55 + tests/tegra/drm-test.c | 261 +++ tests/tegra/drm-test.h | 73 5 files changed, 530 insertions(+), 1 deletion(-) create mode 100644 tests/tegra/drm-test-tegra.c create mode 100644 tests/tegra/drm-test-tegra.h create mode 100644 tests/tegra/drm-test.c create mode 100644 tests/tegra/drm-test.h diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am index 7039f09d38aa..90b11b278a42 100644 --- a/tests/tegra/Makefile.am +++ b/tests/tegra/Makefile.am @@ -4,8 +4,16 @@ AM_CPPFLAGS = \ AM_CFLAGS = -Wall -Werror +noinst_LTLIBRARIES = libdrm-test.la +libdrm_test_la_SOURCES = \ + drm-test.c \ + drm-test.h \ + drm-test-tegra.c \ + drm-test-tegra.h + LDADD = \ - ../../tegra/libdrm_tegra.la + ../../tegra/libdrm_tegra.la \ + libdrm-test.la TESTS = \ openclose \ diff --git a/tests/tegra/drm-test-tegra.c b/tests/tegra/drm-test-tegra.c new file mode 100644 index ..69605b9595b6 --- /dev/null +++ b/tests/tegra/drm-test-tegra.c @@ -0,0 +1,132 @@ +/* + * Copyright ? 2014 NVIDIA Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +#ifdef HAVE_CONFIG_H +# include "config.h" +#endif + +#include +#include + +#include "drm-test-tegra.h" +#include "tegra.h" + +int drm_tegra_gr2d_open(struct drm_tegra_gr2d **gr2dp, struct drm_tegra *drm) +{ + struct drm_tegra_gr2d *gr2d; + int err; + + gr2d = calloc(1, sizeof(*gr2d)); + if (!gr2d) + return -ENOMEM; + + gr2d->drm = drm; + + err = drm_tegra_channel_open(&gr2d->channel, drm, DRM_TEGRA_GR2D); + if (err < 0) { + free(gr2d); + return err; + } + + *gr2dp = gr2d; + + return 0; +} + +int drm_tegra_gr2d_close(struct drm_tegra_gr2d *gr2d) +{ + if (!gr2d) + return -EINVAL; + + drm_tegra_channel_close(gr2d->channel); + free(gr2d); + + return 0; +} + +int drm_tegra_gr2d_fill(struct drm_tegra_gr2d *gr2d, struct drm_framebuffer *fb, + unsigned int x, unsigned int y, unsigned int width, + unsigned int height, uint32_t color) +{ + struct drm_tegra_bo *fbo = fb->data; + struct drm_tegra_pushbuf *pushbuf; + struct drm_tegra_fence *fence; + struct drm_tegra_job *job; + struct drm_tegra_bo *bo; + int err; + + err = drm_tegra_job_new(&job, gr2d->channel); + if (err < 0) + return err; + + err = drm_tegra_bo_new(&bo, gr2d->drm, 0, 4096); + if (err < 0) + return err; + + err = drm_tegra_pushbuf_new(&pushbuf, job, bo, 0); + if (err < 0) + return err; + + *pushbuf->ptr++ = HOST1X_OPCODE_SETCL(0, HOST1X_CLASS_GR2D, 0); + + *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x9, 0x9); + *pushbuf->ptr++ = 0x003a; + *pushbuf->ptr++ = 0x; + + *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x1e, 0x7); + *pushbuf->ptr++ = 0x; + *pushbuf->ptr++ = (2 << 16) | (1 << 6) | (1 << 2); + *pushbuf->ptr++ = 0x00cc; + + *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x2b, 0x9); + drm_tegra_pushbuf_relocate(pushbuf, fbo, 0, 0); + *pushbuf->ptr++ = 0xdeadbeef; + *pushbuf->ptr++ = fb->pitch; + + *pushbuf->ptr++ = HOST1X_OPCODE_NONINCR(0x35, 1); + *pushbuf->ptr++ = color; + + *pushbuf->ptr++ = HOST1X_OPCODE_NONINCR(0x46, 1); + *pushbuf->ptr++ = 0x; + + *pushbuf->ptr++ = HOST1X_OPCODE_MASK(0x38, 0x5); + *pushbuf->ptr++ = height << 16 | width; + *pushbuf->ptr++ = y
[RFC libdrm 6/6] tegra: Add gr2d-fill test
From: Thierry Reding This test uses the IOCTLs for job submission and fences to fill a sub- region of the screen to a specific color using gr2d. Signed-off-by: Thierry Reding --- tests/tegra/Makefile.am | 1 + tests/tegra/gr2d-fill.c | 145 2 files changed, 146 insertions(+) create mode 100644 tests/tegra/gr2d-fill.c diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am index 90b11b278a42..9e9e75e91ad4 100644 --- a/tests/tegra/Makefile.am +++ b/tests/tegra/Makefile.am @@ -17,6 +17,7 @@ LDADD = \ TESTS = \ openclose \ + gr2d-fill if HAVE_INSTALL_TESTS testdir = $(libexecdir)/libdrm/tests/tegra diff --git a/tests/tegra/gr2d-fill.c b/tests/tegra/gr2d-fill.c new file mode 100644 index ..7ffe6f0b0848 --- /dev/null +++ b/tests/tegra/gr2d-fill.c @@ -0,0 +1,145 @@ +/* + * Copyright ? 2014 NVIDIA Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +#ifdef HAVE_CONFIG_H +# include "config.h" +#endif + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +#include "xf86drm.h" +#include "xf86drmMode.h" +#include "drm_fourcc.h" + +#include "drm-test-tegra.h" +#include "tegra.h" + +int main(int argc, char *argv[]) +{ + uint32_t format = DRM_FORMAT_XRGB; + struct drm_tegra_gr2d *gr2d; + struct drm_framebuffer *fb; + struct drm_screen *screen; + unsigned int pitch, size; + struct drm_tegra_bo *bo; + struct drm_tegra *drm; + uint32_t handle; + int fd, err; + void *ptr; + + fd = drm_open(argv[1]); + if (fd < 0) { + fprintf(stderr, "failed to open DRM device %s: %s\n", argv[1], + strerror(errno)); + return 1; + } + + err = drm_screen_open(&screen, fd); + if (err < 0) { + fprintf(stderr, "failed to open screen: %s\n", strerror(-err)); + return 1; + } + + err = drm_tegra_new(&drm, fd); + if (err < 0) { + fprintf(stderr, "failed to create Tegra DRM context: %s\n", + strerror(-err)); + return 1; + } + + err = drm_tegra_gr2d_open(&gr2d, drm); + if (err < 0) { + fprintf(stderr, "failed to open gr2d channel: %s\n", + strerror(-err)); + return 1; + } + + pitch = screen->width * screen->bpp / 8; + size = pitch * screen->height; + + err = drm_tegra_bo_new(&bo, drm, 0, size); + if (err < 0) { + fprintf(stderr, "failed to create buffer object: %s\n", + strerror(-err)); + return 1; + } + + err = drm_tegra_bo_get_handle(bo, &handle); + if (err < 0) { + fprintf(stderr, "failed to get handle to buffer object: %s\n", + strerror(-err)); + return 1; + } + + err = drm_tegra_bo_map(bo, &ptr); + if (err < 0) { + fprintf(stderr, "failed to map buffer object: %s\n", + strerror(-err)); + return 1; + } + + memset(ptr, 0xff, size); + + err = drm_framebuffer_new(&fb, screen, handle, screen->width, + screen->height, pitch, format, bo); + if (err < 0) { + fprintf(stderr, "failed to create framebuffer: %s\n", + strerror(-err)); + return 1; + } + + err = drm_screen_set_framebuffer(screen, fb); + if (err < 0) { + fprintf(stderr, "failed to display framebuffer: %s\n", + strerror(-err)); + return 1; + } + + sleep(1); + + err = drm_tegra_gr2d_fill(gr2d, fb, fb->width / 4, fb->height / 4, + fb->width / 2, fb->height / 2, 0x); +
[Bug 70741] Oops at radeon module (Radeon HD2400 at laptop Asus A8SR)
https://bugzilla.kernel.org/show_bug.cgi?id=70741 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Is this still an issue with a newer kernel? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 70861] New: Radeon KMS Not Triggering On Boot
https://bugzilla.kernel.org/show_bug.cgi?id=70861 Bug ID: 70861 Summary: Radeon KMS Not Triggering On Boot Product: Drivers Version: 2.5 Kernel Version: 3.13.3 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: segaloco at gmail.com Regression: No I recently bumped from 3.13.2 to 3.13.3, and upon bootup, the 'radeon' driver didn't seem to kick-in like usual. I've tried rebooting a couple of times but to no avail. When I booted up the 3.13.2 kernel once again, everything worked fine. I'm not sure what all information you'll need to diagnose what this problem will be, but I'm happy to provide whatever is needed. For starters, my video line in grub.conf (Legacy GRUB) is: video=radeon:mtrr:3,ywrap,1366x768-32 at 60 What I want to stress is that this behavior started with kernel 3.13.3, as everything worked as intended in 3.13.2. My system is loosely based on Gentoo although it is almost entirely upstream packages built by hand now, so there wouldn't be any distro modifications present between kernel versions. All I did for the new kernel is copy .config over from 3.13.2 and ran and exited menuconfig to freshen the file. Please let me know any other information that will help diagnose this problem! Thank you! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 70861] Radeon KMS Not Triggering On Boot
https://bugzilla.kernel.org/show_bug.cgi?id=70861 Matthew Gilmore changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #1 from Matthew Gilmore --- Oh how embarrassing, for some reason or another menuconfig overwrote my .config file even though I copied it over, the driver simply wasn't being built. My bad, you can close this ticket. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75223] New: 3840x2160 HDMI 30Hz fails on XFX r7-240a-clh4 and r7-250a-lzh4
https://bugs.freedesktop.org/show_bug.cgi?id=75223 Priority: medium Bug ID: 75223 Assignee: dri-devel at lists.freedesktop.org Summary: 3840x2160 HDMI 30Hz fails on XFX r7-240a-clh4 and r7-250a-lzh4 Severity: normal Classification: Unclassified OS: Linux (All) Reporter: adam_richter2004 at yahoo.com Hardware: x86 (IA32) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 94377 --> https://bugs.freedesktop.org/attachment.cgi?id=94377&action=edit tar file containing /var/log/Xorg.0.log and logs of dmesg, xrandr, xrandr --verbose for both cards (r7-240 and r7-250) The XFX Radeon r7-240a-clh4 and XFX Radeon r7-250a-zlh4 video cards do not seem to be able to generate 3840x2160 @ 30 Hz video modes over HDMI, even though I believe their hardware is supposed to be capable of this (~299 MHz pixel clock). At least with my se39uy04 39" Seiki television, the Radeon X.org driver happily passed through the five 3840x2160 @ 24-30 Hz that the television's advertises in its EDID modes to xrandr, meaning that driver thinks it can support those video modes, but, if I select any of them, the telvision just says "mode not support." In comparison, if I make a custom video mode for 3840x2160 @ 15Hz, the 4k TV displays that fine. I am attaching a .tar.gz file containting /var/log/Xorg.0.log and logs of dmesg, xrandr, xrandr --verbose for both cards (r7-240 and r7-250). Thanks to Alex Deucher for advising me to file this bug report here. Thanks in advance for any further processing of this bug report. -- 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/20140219/4c3462d8/attachment.html>
[Bug 75211] radeonsi/llvm SIGABRT in Antichamber (UDK)
https://bugs.freedesktop.org/show_bug.cgi?id=75211 Christoph Haag changed: What|Removed |Added Attachment #94363|0 |1 is obsolete|| --- Comment #1 from Christoph Haag --- Created attachment 94379 --> https://bugs.freedesktop.org/attachment.cgi?id=94379&action=edit first short backtrace, then full backtrace with debug symbols Okay, so here is a full backtrace with debugging information. -- 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/20140219/5494d917/attachment.html>
[Bug 70706] Regression in fbconfig
https://bugs.freedesktop.org/show_bug.cgi?id=70706 --- Comment #20 from Joseph Yasi --- (In reply to comment #19) > Might be worth testing these two patches [1] [2] > > [1] http://patchwork.freedesktop.org/patch/20458/ > [2] http://patchwork.freedesktop.org/patch/20464/ Those patches fixed it for me. -- You are receiving this mail because: You are on the CC list for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/8cf7fdd5/attachment-0001.html>
[PATCH libdrm] Mark functions printf-like where possible
Thierry Reding writes: > From: Thierry Reding > > These functions all take a format string and either a list of variable > arguments or a va_list. Use the new DRM_PRINTFLIKE macro to tell the > compiler about it so that the arguments can be checked against the > format string. Reviewed-by: Eric Anholt -- 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/20140219/8277d5c1/attachment.pgp>
[PATCH libdrm] tests: Use drmFreeVersion() instead of drmFree()
Thierry Reding writes: > From: Thierry Reding > > drmFreeVersion() frees the memory allocated for the name, date and desc > fields in addition to that for the struct _drmVersion. > > Signed-off-by: Thierry Reding Reviewed-by: Eric Anholt -- 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/20140219/53a195fd/attachment.pgp>
[Bug 75211] radeonsi/llvm SIGABRT in Antichamber (UDK)
https://bugs.freedesktop.org/show_bug.cgi?id=75211 --- Comment #2 from Christoph Haag --- Created attachment 94380 --> https://bugs.freedesktop.org/attachment.cgi?id=94380&action=edit last few lines before crash with MESA_GLSL=dump So because it looks like it happens when compiling shaders I ran it with MESA_GLSL=dump. It loads and compiles most shaders at the beginning, that worked fine so I cut it off. It occassionally seems to load new shaders, so after a while of gameplay with no output the attached stuff was printed and then immediately after that the game crashed. -- 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/20140219/20c9ad99/attachment.html>
[radeonsi] ss percentage divider in dpm
Hi, The commit 18f8f52b9a8c293111c058f9d25bcd5e718b80b2 does introduce the ss percentage divider. This divider is not used in si_populate_mclk_value and si_calculate_sclk_params. Expected? -- Sylvain
[RFC libdrm 4/6] tegra: Add channel, job, pushbuf and fence APIs
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > From: Thierry Reding > > These functions can be used to open channels to engines, manage job > submissions, create push buffers to store command streams in and wait > until jobs have been completed. > > Signed-off-by: Thierry Reding Thanks a lot for doing this! I'm going right for the juicy patch ;) > +drm_public > +int drm_tegra_fence_wait_timeout(struct drm_tegra_fence *fence, > +unsigned long timeout) > +{ > + struct drm_tegra_syncpt_wait args; > + int err; > + > + memset(&args, 0, sizeof(args)); Nit: how about struct drm_tegra_syncpt_wait args = { 0 }; instead? > + args.id = fence->syncpt; > + args.thresh = fence->value; > + args.timeout = timeout; > + > + while (true) { > + err = ioctl(fence->drm->fd, DRM_IOCTL_TEGRA_SYNCPT_WAIT, > &args); > + if (err < 0) { > + if (errno == EINTR) > + continue; > + > + drmMsg("DRM_IOCTL_TEGRA_SYNCPT_WAIT: %d\n", -errno); What's the reason for printing the errno negated? And could we do '...%s\n" strerror(errno));' instead? > +int drm_tegra_job_add_reloc(struct drm_tegra_job *job, > + const struct drm_tegra_reloc *reloc) > +{ > + struct drm_tegra_reloc *relocs; > + size_t size; > + > + size = (job->num_relocs + 1) * sizeof(*reloc); > + > + relocs = realloc(job->relocs, size); Nit: there's no point in not assigning those while declaring them, no? size_t size = (job->num_relocs + 1) * sizeof(*reloc); struct drm_tegra_reloc *relocs; = realloc(job->relocs, size); > +drm_public > +int drm_tegra_pushbuf_new(struct drm_tegra_pushbuf **pushbufp, > + struct drm_tegra_job *job, > + struct drm_tegra_bo *bo, > + unsigned long offset) > +{ > + struct drm_tegra_pushbuf_private *pushbuf; > + void *ptr; > + int err; > + > + pushbuf = calloc(1, sizeof(*pushbuf)); > + if (!pushbuf) > + return -ENOMEM; > + > + pushbuf->bo = drm_tegra_bo_get(bo); > + DRMINITLISTHEAD(&pushbuf->list); > + pushbuf->job = job; > + > + err = drm_tegra_bo_map(bo, &ptr); > + if (err < 0) { > + drm_tegra_bo_put(bo); > + free(pushbuf); > + return err; > + } > + > + pushbuf->start = pushbuf->base.ptr = ptr + offset; > + pushbuf->offset = offset; > + > + DRMLISTADD(&pushbuf->list, &job->pushbufs); > + job->num_pushbufs++; > + > + *pushbufp = &pushbuf->base; > + > + return 0; > +} It feels quite wasteful to me to have to allocate a new pushbuf in order to be able to use a new BO. I'd much rather see the pushbuf being a persisting object that's the interface to the command-stream (that produces jobs). I was thinking something like: int drm_tegra_pushbuf_new(struct drm_tegra_pushbuf **pushbufp, struct drm_tegra_job *job) int drm_tegra_pushbuf_room(struct drm_tegra_pushbuf *pushbuf, int num_words); Where room guarantees that there's space for those words in the pushbuf. A simple implementation could just allocate a bo of that size, but a slightly more sophisticated one can allocate larger ones and reuse them. Even more sophisticated ones could keep old cmdbufs around and reuse them once the hardware is done reading them, do exponential grow-factors etc. I've implemented the "slightly more sophisticated" approach here: https://github.com/grate-driver/libdrm/commit/f90ea2f57ca4d8c81768402900c663ce526bac11 In my implementation, I've changed the job-structure to build the list of cmdbufs directly rather than keeping a list of the pushbufs. Sure, that means another allocation every time we need a new cmdbuf, but hopefully we should be able to produce much less of them this way. > +int drm_tegra_pushbuf_relocate(struct drm_tegra_pushbuf *pushbuf, > + struct drm_tegra_bo *target, > + unsigned long offset, > + unsigned long shift) > +{ > + struct drm_tegra_pushbuf_private *priv = pushbuf_priv(pushbuf); > + struct drm_tegra_reloc reloc; > + int err; > + > + memset(&reloc, 0, sizeof(reloc)); > + reloc.cmdbuf.handle = priv->bo->handle; > + reloc.cmdbuf.offset = drm_tegra_pushbuf_get_offset(pushbuf); > + reloc.target.handle = target->handle; > + reloc.target.offset = offset; > + reloc.shift = shift; > + > + err = drm_tegra_job_add_reloc(priv->job, &reloc); > + if (err < 0) > + return err; > + > + return 0; > +} Whenever we insert a reloc, we also insert a DEADBEEF in the command stream. Why not formalize this into this function?
[RFC libdrm 2/6] libdrm: Add NVIDIA Tegra support
Le mercredi 19 f?vrier 2014 ? 17:04 +0100, Thierry Reding a ?crit : > --- /dev/null > +++ b/include/drm/tegra_drm.h > @@ -0,0 +1,157 @@ > +/* > + * Copyright (c) 2012-2013, NVIDIA CORPORATION. All rights reserved. ^^ [...] > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS > + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. > + * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR ^ So whose code is this? Wouldn't it be better to say "the above copyright owners" instead? Other than that, I have no valuable review to offer. Cheers, R?mi
[RFC libdrm 2/6] libdrm: Add NVIDIA Tegra support
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > +#ifndef __DRM_TEGRA_PRIVATE_H__ > +#define __DRM_TEGRA_PRIVATE_H__ 1 > + > +#include > +#include > + > +#include > + > +#include "tegra.h" > + > +#if defined(HAVE_VISIBILITY) > +# define drm_private __attribute__((visibility("hidden"))) > +# define drm_public __attribute__((visibility("default"))) > +#else > +# define drm_private > +# define drm_public > +#endif > + Perhaps you could put this where it's visible to other drivers as well, like xf86drm.h?
[RFC libdrm 2/6] libdrm: Add NVIDIA Tegra support
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > diff --git a/tegra/Makefile.am b/tegra/Makefile.am > new file mode 100644 > index ..1b83145b120d > --- /dev/null > +++ b/tegra/Makefile.am > @@ -0,0 +1,20 @@ > +AM_CPPFLAGS = \ > + -I$(top_srcdir) \ > + -I$(top_srcdir)/include/drm > + > +AM_CFLAGS = \ > + $(VISIBILITY_CFLAGS) > + > +libdrm_tegra_ladir = $(libdir) > +libdrm_tegra_la_LTLIBRARIES = libdrm_tegra.la > +libdrm_tegra_la_LDFLAGS = -version-number 0:0:0 -no-undefined > +libdrm_tegra_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@ > + > +libdrm_tegra_la_SOURCES = \ > + tegra.c > + > +libdrm_tegraincludedir = ${includedir}/libdrm > +libdrm_tegrainclude_HEADERS = tegra.h > + > +pkgconfigdir = @pkgconfigdir@ > +pkgconfig_DATA = libdrm_tegra.pc You should probably also add libdrm_tegra.pc to .gitignore also.
[RFC libdrm 3/6] tegra: Add simple test for drm_tegra_open()
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am > new file mode 100644 > index ..7039f09d38aa > --- /dev/null > +++ b/tests/tegra/Makefile.am > @@ -0,0 +1,20 @@ > +AM_CPPFLAGS = \ > + -I$(top_srcdir)/include/drm \ > + -I$(top_srcdir)/tegra > + > +AM_CFLAGS = -Wall -Werror > + > +LDADD = \ > + ../../tegra/libdrm_tegra.la You also need to add ../../libdrm.la here.
[Bug 75226] New: Dark rendering of War for the Overworld
https://bugs.freedesktop.org/show_bug.cgi?id=75226 Priority: medium Bug ID: 75226 Assignee: dri-devel at lists.freedesktop.org Summary: Dark rendering of War for the Overworld Severity: normal Classification: Unclassified OS: Linux (All) Reporter: ehoover at mines.edu Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI I am doing volunteer tech support for Linux users of War for the Overworld and I've had a couple radeon users report problems with the game being rendered very dark ( https://forum.subterraneangames.com/attachments/menu2-png.2894/ ): https://forum.subterraneangames.com/threads/ingame-colors-to-dark-to-play.4941/ When I replay their apitrace on my own machine (nVidia card) I do not see such issues, and have not had reports from any non-radeon users, so I suspect that something is being done incorrectly in the driver. I'm happy to work as an intermediary for these users in order to collect more information and would happily provide a link to user apitraces if that would 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/20140219/2ef9a053/attachment.html>
dri-top?
Hey, I should know this but I am bit behind on the latest of the drm-debug tools. Is there a way to figure out which applications are using GEM/TTM buffers? Or just even a simpler - which application is using which DRM pages? Michael (CC-ed here) is finding that TTM is hitting the memory ceiling quite often and we are not sure whether the problem is with a leaking application or something entirely different. Thanks!
[RFC libdrm 3/6] tegra: Add simple test for drm_tegra_open()
On Wed, Feb 19, 2014 at 9:19 PM, Erik Faye-Lund wrote: > On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding > wrote: >> diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am >> new file mode 100644 >> index ..7039f09d38aa >> --- /dev/null >> +++ b/tests/tegra/Makefile.am >> @@ -0,0 +1,20 @@ >> +AM_CPPFLAGS = \ >> + -I$(top_srcdir)/include/drm \ >> + -I$(top_srcdir)/tegra >> + >> +AM_CFLAGS = -Wall -Werror >> + >> +LDADD = \ >> + ../../tegra/libdrm_tegra.la > > You also need to add ../../libdrm.la here. But even so, "make check" fails without any explanation. However, gr2d-fill also fails. But with an error: "failed to open DRM device (null): Bad address". Judging from the source-code, it seems they expect arguments that "make check" doesn't provide.
[RFC libdrm 5/6] tegra: Add helper library for tests
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > diff --git a/tests/tegra/drm-test-tegra.h b/tests/tegra/drm-test-tegra.h > new file mode 100644 > index ..d1cb6b1ee440 > --- /dev/null > +++ b/tests/tegra/drm-test-tegra.h > +int drm_open(const char *path) > +{ > + int fd, err; > + > + fd = open(path, O_RDWR); > + if (fd < 0) > + return -errno; > + > + err = drmSetMaster(fd); Hmmpf, do we really need modesetting for all tests? Can't tests opt-in on that instead?
[RFC libdrm 6/6] tegra: Add gr2d-fill test
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > From: Thierry Reding > > This test uses the IOCTLs for job submission and fences to fill a sub- > region of the screen to a specific color using gr2d. > > Signed-off-by: Thierry Reding > --- > tests/tegra/Makefile.am | 1 + > tests/tegra/gr2d-fill.c | 145 > > 2 files changed, 146 insertions(+) > create mode 100644 tests/tegra/gr2d-fill.c > > diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am > index 90b11b278a42..9e9e75e91ad4 100644 > --- a/tests/tegra/Makefile.am > +++ b/tests/tegra/Makefile.am > @@ -17,6 +17,7 @@ LDADD = \ > > TESTS = \ > openclose \ > + gr2d-fill > > if HAVE_INSTALL_TESTS > testdir = $(libexecdir)/libdrm/tests/tegra > diff --git a/tests/tegra/gr2d-fill.c b/tests/tegra/gr2d-fill.c > new file mode 100644 > index ..7ffe6f0b0848 > --- /dev/null > +++ b/tests/tegra/gr2d-fill.c > @@ -0,0 +1,145 @@ > +/* > + * Copyright ? 2014 NVIDIA Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be included in > + * all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR > + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > + * OTHER DEALINGS IN THE SOFTWARE. > + */ > + > +#ifdef HAVE_CONFIG_H > +# include "config.h" > +#endif > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + > +#include "xf86drm.h" > +#include "xf86drmMode.h" > +#include "drm_fourcc.h" > + > +#include "drm-test-tegra.h" > +#include "tegra.h" > + > +int main(int argc, char *argv[]) > +{ > + uint32_t format = DRM_FORMAT_XRGB; > + struct drm_tegra_gr2d *gr2d; > + struct drm_framebuffer *fb; > + struct drm_screen *screen; > + unsigned int pitch, size; > + struct drm_tegra_bo *bo; > + struct drm_tegra *drm; > + uint32_t handle; > + int fd, err; > + void *ptr; > + > + fd = drm_open(argv[1]); > + if (fd < 0) { > + fprintf(stderr, "failed to open DRM device %s: %s\n", argv[1], > + strerror(errno)); > + return 1; > + } > + > + err = drm_screen_open(&screen, fd); > + if (err < 0) { > + fprintf(stderr, "failed to open screen: %s\n", > strerror(-err)); > + return 1; > + } > + > + err = drm_tegra_new(&drm, fd); > + if (err < 0) { > + fprintf(stderr, "failed to create Tegra DRM context: %s\n", > + strerror(-err)); > + return 1; > + } > + > + err = drm_tegra_gr2d_open(&gr2d, drm); > + if (err < 0) { > + fprintf(stderr, "failed to open gr2d channel: %s\n", > + strerror(-err)); > + return 1; > + } > + > + pitch = screen->width * screen->bpp / 8; > + size = pitch * screen->height; > + > + err = drm_tegra_bo_new(&bo, drm, 0, size); > + if (err < 0) { > + fprintf(stderr, "failed to create buffer object: %s\n", > + strerror(-err)); > + return 1; > + } > + > + err = drm_tegra_bo_get_handle(bo, &handle); > + if (err < 0) { > + fprintf(stderr, "failed to get handle to buffer object: %s\n", > + strerror(-err)); > + return 1; > + } > + > + err = drm_tegra_bo_map(bo, &ptr); > + if (err < 0) { > + fprintf(stderr, "failed to map buffer object: %s\n", > + strerror(-err)); > + return 1; > + } > + > + memset(ptr, 0xff, size); > + > + err = drm_framebuffer_new(&fb, screen, handle, screen->width, > + screen->height, pitch, format, bo); > + if (err < 0) { > + fprintf(stderr, "failed to create framebuffer: %s\n", > + strerror(-err)); > + return 1; > + } > + > + err = drm_screen_set_framebuffer(screen,
[RFC libdrm 1/6] configure: Support symbol visibility when available
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > From: Thierry Reding > > Checks whether or not the compiler supports the -fvisibility option. If > so it sets the VISIBILITY_CFLAGS variable which can be added to the per > directory AM_CFLAGS where appropriate. > > Libraries can use the HAVE_VISIBILITY preprocessor definition to check > for availability and use something like this: > > #if defined(HAVE_VISIBILITY) > # define drm_private __attribute__((visibility("hidden"))) > # define drm_public __attribute__((visibility("default"))) > #else > # define drm_private > # define drm_public > #endif > > By default all symbols will be hidden via the VISIBILITY_CFLAGS. Only > symbols explicitly marked drm_public will be exported. As I said in the other patch, I think it makes more sense to define these globally. The other drivers still need to opt-in on the feature, but it's less work, less duplication of logic and less points-of-failure ;)
[RFC libdrm 4/6] tegra: Add channel, job, pushbuf and fence APIs
buffer objects are handled entirely by the push buffer implementation? Yeah, I think that makes a lot of sense actually. > I've implemented the "slightly more sophisticated" approach here: > > https://github.com/grate-driver/libdrm/commit/f90ea2f57ca4d8c81768402900c663ce526bac11 > > In my implementation, I've changed the job-structure to build the list > of cmdbufs directly rather than keeping a list of the pushbufs. Sure, > that means another allocation every time we need a new cmdbuf, but > hopefully we should be able to produce much less of them this way. Okay, I'll try to integrate your implementation. It looks somewhat complex but still manageable. The important part at this point is to get the API right. That way we can still implement whatever complex scheme we want underneath. > > +int drm_tegra_pushbuf_relocate(struct drm_tegra_pushbuf *pushbuf, > > + struct drm_tegra_bo *target, > > + unsigned long offset, > > + unsigned long shift) > > +{ > > + struct drm_tegra_pushbuf_private *priv = pushbuf_priv(pushbuf); > > + struct drm_tegra_reloc reloc; > > + int err; > > + > > + memset(&reloc, 0, sizeof(reloc)); > > + reloc.cmdbuf.handle = priv->bo->handle; > > + reloc.cmdbuf.offset = drm_tegra_pushbuf_get_offset(pushbuf); > > + reloc.target.handle = target->handle; > > + reloc.target.offset = offset; > > + reloc.shift = shift; > > + > > + err = drm_tegra_job_add_reloc(priv->job, &reloc); > > + if (err < 0) > > + return err; > > + > > + return 0; > > +} > > Whenever we insert a reloc, we also insert a DEADBEEF in the command > stream. Why not formalize this into this function? That's a good idea. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/d22030d5/attachment.pgp>
[RFC libdrm 2/6] libdrm: Add NVIDIA Tegra support
On Wed, Feb 19, 2014 at 09:13:31PM +0100, Erik Faye-Lund wrote: > On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding > wrote: > > diff --git a/tegra/Makefile.am b/tegra/Makefile.am > > new file mode 100644 > > index ..1b83145b120d > > --- /dev/null > > +++ b/tegra/Makefile.am > > @@ -0,0 +1,20 @@ > > +AM_CPPFLAGS = \ > > + -I$(top_srcdir) \ > > + -I$(top_srcdir)/include/drm > > + > > +AM_CFLAGS = \ > > + $(VISIBILITY_CFLAGS) > > + > > +libdrm_tegra_ladir = $(libdir) > > +libdrm_tegra_la_LTLIBRARIES = libdrm_tegra.la > > +libdrm_tegra_la_LDFLAGS = -version-number 0:0:0 -no-undefined > > +libdrm_tegra_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@ > > + > > +libdrm_tegra_la_SOURCES = \ > > + tegra.c > > + > > +libdrm_tegraincludedir = ${includedir}/libdrm > > +libdrm_tegrainclude_HEADERS = tegra.h > > + > > +pkgconfigdir = @pkgconfigdir@ > > +pkgconfig_DATA = libdrm_tegra.pc > > You should probably also add libdrm_tegra.pc to .gitignore also. Done. Thanks, Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/78d8e9d2/attachment.pgp>
[RFC libdrm 2/6] libdrm: Add NVIDIA Tegra support
On Wed, Feb 19, 2014 at 09:03:51PM +0100, Erik Faye-Lund wrote: > On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding > wrote: > > +#ifndef __DRM_TEGRA_PRIVATE_H__ > > +#define __DRM_TEGRA_PRIVATE_H__ 1 > > + > > +#include > > +#include > > + > > +#include > > + > > +#include "tegra.h" > > + > > +#if defined(HAVE_VISIBILITY) > > +# define drm_private __attribute__((visibility("hidden"))) > > +# define drm_public __attribute__((visibility("default"))) > > +#else > > +# define drm_private > > +# define drm_public > > +#endif > > + > > Perhaps you could put this where it's visible to other drivers as > well, like xf86drm.h? I'd prefer to keep this here for now. We can move it to a more central location when another module starts using it. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/12cffa07/attachment.pgp>
[RFC libdrm 3/6] tegra: Add simple test for drm_tegra_open()
On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding wrote: > From: Thierry Reding > > This test opens a device, dumps the version information and checks that > a Tegra DRM context can be opened on it. > > Signed-off-by: Thierry Reding > --- > configure.ac| 1 + > tests/Makefile.am | 4 > tests/tegra/Makefile.am | 20 > tests/tegra/openclose.c | 63 > + > 4 files changed, 88 insertions(+) > create mode 100644 tests/tegra/Makefile.am > create mode 100644 tests/tegra/openclose.c > > diff --git a/configure.ac b/configure.ac > index 752a70592933..c4ae14e8d2e1 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -421,6 +421,7 @@ AC_CONFIG_FILES([ > tests/radeon/Makefile > tests/vbltest/Makefile > tests/exynos/Makefile > + tests/tegra/Makefile > include/Makefile > include/drm/Makefile > man/Makefile > diff --git a/tests/Makefile.am b/tests/Makefile.am > index cd1149130214..0a3d21f2d99f 100644 > --- a/tests/Makefile.am > +++ b/tests/Makefile.am > @@ -24,6 +24,10 @@ if HAVE_EXYNOS > SUBDIRS += exynos > endif > > +if HAVE_TEGRA > +SUBDIRS += tegra > +endif > + > if HAVE_LIBUDEV > > check_LTLIBRARIES = libdrmtest.la > diff --git a/tests/tegra/Makefile.am b/tests/tegra/Makefile.am > new file mode 100644 > index ..7039f09d38aa > --- /dev/null > +++ b/tests/tegra/Makefile.am > @@ -0,0 +1,20 @@ > +AM_CPPFLAGS = \ > + -I$(top_srcdir)/include/drm \ > + -I$(top_srcdir)/tegra > + > +AM_CFLAGS = -Wall -Werror > + > +LDADD = \ > + ../../tegra/libdrm_tegra.la > + > +TESTS = \ > + openclose \ > + > +if HAVE_INSTALL_TESTS > +testdir = $(libexecdir)/libdrm/tests/tegra > +test_PROGRAMS = \ > + $(TESTS) > +else > +noinst_PROGRAMS = $(TESTS) > +check_PROGRAMS = $(TESTS) > +endif You should probably add openclose to .gitignore also. The same goes for gr2d-fill in the other commit.
[RFC libdrm 6/6] tegra: Add gr2d-fill test
tch = screen->width * screen->bpp / 8; > > + size = pitch * screen->height; > > + > > + err = drm_tegra_bo_new(&bo, drm, 0, size); > > + if (err < 0) { > > + fprintf(stderr, "failed to create buffer object: %s\n", > > + strerror(-err)); > > + return 1; > > + } > > + > > + err = drm_tegra_bo_get_handle(bo, &handle); > > + if (err < 0) { > > + fprintf(stderr, "failed to get handle to buffer object: > > %s\n", > > + strerror(-err)); > > + return 1; > > + } > > + > > + err = drm_tegra_bo_map(bo, &ptr); > > + if (err < 0) { > > + fprintf(stderr, "failed to map buffer object: %s\n", > > + strerror(-err)); > > + return 1; > > + } > > + > > + memset(ptr, 0xff, size); > > + > > + err = drm_framebuffer_new(&fb, screen, handle, screen->width, > > + screen->height, pitch, format, bo); > > + if (err < 0) { > > + fprintf(stderr, "failed to create framebuffer: %s\n", > > + strerror(-err)); > > + return 1; > > + } > > + > > + err = drm_screen_set_framebuffer(screen, fb); > > + if (err < 0) { > > + fprintf(stderr, "failed to display framebuffer: %s\n", > > + strerror(-err)); > > + return 1; > > + } > > + > > + sleep(1); > > + > > + err = drm_tegra_gr2d_fill(gr2d, fb, fb->width / 4, fb->height / 4, > > + fb->width / 2, fb->height / 2, > > 0x); > > + if (err < 0) { > > + fprintf(stderr, "failed to fill rectangle: %s\n", > > + strerror(-err)); > > + return 1; > > + } > > + > > + sleep(1); > > Oh, I see. You don't validate the result from the code, but visually instead? > > IMO, we should allow automated test to verify the result > automatically. GR2D doesn't care about modesetting. > > We could of course have a switch that lets the test-result be > inspected visually when specified. But I don't think that should be > the default, as it's more error prone, and requires master-rights. Yes, I think we should support both. Offscreen tests for automatic validation and onscreen tests for me because I like looking at the output. One of the things also on my TODO list, and with these patches getting ready that moves more towards the top, is render node support. It should be relatively easy to support that. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/c7a8f5ab/attachment-0001.pgp>
[RFC libdrm 1/6] configure: Support symbol visibility when available
On Wed, Feb 19, 2014 at 10:05:19PM +0100, Erik Faye-Lund wrote: > On Wed, Feb 19, 2014 at 5:04 PM, Thierry Reding > wrote: > > From: Thierry Reding > > > > Checks whether or not the compiler supports the -fvisibility option. If > > so it sets the VISIBILITY_CFLAGS variable which can be added to the per > > directory AM_CFLAGS where appropriate. > > > > Libraries can use the HAVE_VISIBILITY preprocessor definition to check > > for availability and use something like this: > > > > #if defined(HAVE_VISIBILITY) > > # define drm_private __attribute__((visibility("hidden"))) > > # define drm_public __attribute__((visibility("default"))) > > #else > > # define drm_private > > # define drm_public > > #endif > > > > By default all symbols will be hidden via the VISIBILITY_CFLAGS. Only > > symbols explicitly marked drm_public will be exported. > > As I said in the other patch, I think it makes more sense to define > these globally. The other drivers still need to opt-in on the feature, > but it's less work, less duplication of logic and less > points-of-failure ;) Well, if you put it that way, having it in somewhere in the core might be a better option after all. I'll sleep on it. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140219/fdf75166/attachment.pgp>
[PATCH] host1x: export host1x_syncpt_incr_max function
On 02/19/2014 03:23 PM, Bryan Wu wrote: > Tegra V4L2 camera driver needs this function to do frame capture. Does it need to be EXPORT_SYMBOL()d too, in case things are modules?
[Bug 75226] Dark rendering of War for the Overworld
https://bugs.freedesktop.org/show_bug.cgi?id=75226 Alex Deucher changed: What|Removed |Added Product|DRI |Mesa Component|DRM/Radeon |Drivers/Gallium/r600 --- Comment #1 from Alex Deucher --- What hardware and version of the driver are in use? If possible, please attach the xorg log, and the output of dmesg and glxinfo. -- 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/20140219/a69f4e17/attachment.html>
[radeonsi] ss percentage divider in dpm
On Wed, Feb 19, 2014 at 2:54 PM, Sylvain BERTRAND wrote: > Hi, > > The commit 18f8f52b9a8c293111c058f9d25bcd5e718b80b2 does > introduce the ss percentage divider. > > This divider is not used in si_populate_mclk_value and > si_calculate_sclk_params. > > Expected? The divider differences only apply to display clock ss. Alex > > -- > Sylvain > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update
> -Original Message- > From: Ville Syrj?l? [mailto:ville.syrjala at linux.intel.com] > Sent: Tuesday, February 18, 2014 10:23 PM > To: Lin, Mengdong > Cc: Daniel Vetter; Takashi Iwai; alsa-devel at alsa-project.org; Barnes, > Jesse; > Zanoni, Paulo R; dri-devel; intel-gfx at lists.freedesktop.org > Subject: Re: [Intel-gfx] Need your advice: Add a new communication > inteface between HD-Audio and Gfx drivers for hotplug notification/ELD > update > > On Tue, Feb 18, 2014 at 01:58:22PM +, Lin, Mengdong wrote: > > Sorry to pick up this thread after a long time. > > > > > -Original Message- > > > From: daniel.vetter at ffwll.ch [mailto:daniel.vetter at ffwll.ch] On > > > Behalf Of Daniel Vetter > > > Sent: Thursday, January 23, 2014 4:27 PM > > > To: Takashi Iwai > > > > > On Thu, Jan 23, 2014 at 8:57 AM, Takashi Iwai wrote: > > > >> Thanks for clarification! > > > >> Maybe we can add output info (eg. display port number) to the eld > > > >> entries > > > under /proc/asound/cardx. Is it okay? > > > > > > > > It's possible, but the proc file is just a help. It can't be the API. > > > > For accessing the information, we'll need some new API, or let > > > > inform via sysfs of the new device. > > > > > > Links in sysfs sound like the best approach. drm already has nodes > > > for each connector, so on the gfx side there's a natural endpoint > already. > > > sysfs links also avoids any naming issues from the start, e.g. the > > > above DP connector id might lead to clashes with multiple cards. > > > > Hi Daniel, > > > > Is there a 1:1 mapping between these connector nodes and ports of Gfx > display engine? > > Eg. For Haswell Ultrabook, under > > /sys/devices/pci:00/:00:02.0/drm/card0/ > > There are four connector nodes, > > card0-DP-1 -> DDI port B > > card0-eDP-1/-> DDI port A > > card0-HDMI-A-1/ -> DDI Port C > > card0-HDMI-A-2/ -> Which DDI port ? Haswell-ULT does not > support port D, and I think port E is for VGA. > > There's no fixed mapping with the port and the connector name. The > number in the connector name is basically just a running number per > connector type. However I do believe we do register the connectors in the > order of the ports more or less always, so you can > *sometimes* deduce the port name from the connector. > > I suppose in this example HDMI-A-1 is port B, HDMI-A-2 is port C, and > DP-1 can be either port B or port C. DP++ is the reason why we have > overlapping DP and HDMI connectors for the same port. Thanks for clarification, Ville! Does Haswell support DP++ on port B/C/D? And will the name of these connector node change after system boot, e.g. after S3/S4 cycles or hot-plug? As long as the connector name is constant, it can help to find out the screen status no matter the port works in HDMI or DP mode. There is 1:1 mapping between audio output pins and DDI ports. And the new ALSA PCM 'screen' control for a pin can reflect the connector name in right mode. E.g. for pin/port B, it can return HDMI-A-1 or DP-1 depending on what kind of monitor is connected. Thanks Mengdong > > > > Hi Takashi, > > > > To make user space figure out which audio output is connected to which > screen (connector), maybe we can define a new ALSA control for each > HDMI/DP PCM device: > > e.g. numid=x,iface=PCM,name='Screen',device=3 > > Reading the control will return the name of the DRM connector nodes > like ' card0-DP-1'. The audio driver can get the connector name from the > gfx driver. > > > > For DP1.2 Multi-stream transport, it's not supported by i915 and HD-A > driver now. But probably there will be sub-nodes for the DP connector > node in the future and an index in their name can be used distinguish > monitors connected to the same DP port, like card0-DP-1.1, card0-DP-1.2, > card0-DP-1.3 ... These names can be used by the above ALSA PCM 'Screen' > control, so we can still know which audio output is to which monitor. > > > > Thanks > > Mengdong > > > > ___ > > Intel-gfx mailing list > > Intel-gfx at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrj?l? > Intel OTC
[PATCH] nouveau, ACPI: fix regression caused by b072e53
On some platforms, ACPI _DSM method (nouveau_op_dsm_muid, function 0) has special requirements on the fourth parameter, which is different from ACPI specifications. So revert to the private implementation to check availability of _DSM functions instead of using common acpi_check_dsm() interface. Signed-off-by: Jiang Liu --- Hi Maarten, Thanks for bisecting. Could you please help to verify whether this patch fixes the regression? Thanks! Gerry --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/nouveau_acpi.c index 4ef83df..c6c7d0d 100644 --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c @@ -106,6 +106,29 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, int arg, uint32_t * return 0; } +/* + * On some platforms, _DSM(nouveau_op_dsm_muid, func0) has special + * requirements on the fourth parameter, so a private implementation + * instead of using acpi_check_dsm(). + */ +static int nouveau_check_optimus_dsm(acpi_handle handle) +{ + int result; + + /* +* Function 0 returns a Buffer containing available functions. +* The args parameter is ignored for function 0, so just put 0 in it +*/ + if (nouveau_optimus_dsm(handle, 0, 0, &result) + return 0; + + /* +* ACPI Spec v4 9.14.1: if bit 0 is zero, no function is supported. +* If the n-th bit is enabled, function n is supported +*/ + return result & 1 && result & (1 << NOUVEAU_DSM_OPTIMUS_CAPS); +} + static int nouveau_dsm(acpi_handle handle, int func, int arg) { int ret = 0; @@ -207,8 +230,7 @@ static int nouveau_dsm_pci_probe(struct pci_dev *pdev) 1 << NOUVEAU_DSM_POWER)) retval |= NOUVEAU_DSM_HAS_MUX; - if (acpi_check_dsm(dhandle, nouveau_op_dsm_muid, 0x0100, - 1 << NOUVEAU_DSM_OPTIMUS_CAPS)) + if (nouveau_check_optimus_dsm(dhandle)) retval |= NOUVEAU_DSM_HAS_OPT; if (retval & NOUVEAU_DSM_HAS_OPT) { -- 1.7.10.4
[PATCH] nouveau, ACPI: fix regression caused by b072e53
Hi Maarten, Forgot to refresh my working tree. Please help to apply this patch on top of previous one to solve a compilation bug. diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c b/drivers/gpu/drm/nouveau/no index c6c7d0d..83face3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c @@ -119,7 +119,7 @@ static int nouveau_check_optimus_dsm(acpi_handle handle) * Function 0 returns a Buffer containing available functions. * The args parameter is ignored for function 0, so just put 0 in it */ - if (nouveau_optimus_dsm(handle, 0, 0, &result) + if (nouveau_optimus_dsm(handle, 0, 0, &result)) return 0; On 2014/2/19 12:53, Jiang Liu wrote: > On some platforms, ACPI _DSM method (nouveau_op_dsm_muid, function 0) > has special requirements on the fourth parameter, which is different > from ACPI specifications. So revert to the private implementation > to check availability of _DSM functions instead of using common > acpi_check_dsm() interface. > > Signed-off-by: Jiang Liu > --- > Hi Maarten, > Thanks for bisecting. Could you please help to verify whether > this patch fixes the regression? > > Thanks! > Gerry > --- > drivers/gpu/drm/nouveau/nouveau_acpi.c | 26 -- > 1 file changed, 24 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c > b/drivers/gpu/drm/nouveau/nouveau_acpi.c > index 4ef83df..c6c7d0d 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c > +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c > @@ -106,6 +106,29 @@ static int nouveau_optimus_dsm(acpi_handle handle, int > func, int arg, uint32_t * > return 0; > } > > +/* > + * On some platforms, _DSM(nouveau_op_dsm_muid, func0) has special > + * requirements on the fourth parameter, so a private implementation > + * instead of using acpi_check_dsm(). > + */ > +static int nouveau_check_optimus_dsm(acpi_handle handle) > +{ > + int result; > + > + /* > + * Function 0 returns a Buffer containing available functions. > + * The args parameter is ignored for function 0, so just put 0 in it > + */ > + if (nouveau_optimus_dsm(handle, 0, 0, &result) > + return 0; > + > + /* > + * ACPI Spec v4 9.14.1: if bit 0 is zero, no function is supported. > + * If the n-th bit is enabled, function n is supported > + */ > + return result & 1 && result & (1 << NOUVEAU_DSM_OPTIMUS_CAPS); > +} > + > static int nouveau_dsm(acpi_handle handle, int func, int arg) > { > int ret = 0; > @@ -207,8 +230,7 @@ static int nouveau_dsm_pci_probe(struct pci_dev *pdev) > 1 << NOUVEAU_DSM_POWER)) > retval |= NOUVEAU_DSM_HAS_MUX; > > - if (acpi_check_dsm(dhandle, nouveau_op_dsm_muid, 0x0100, > -1 << NOUVEAU_DSM_OPTIMUS_CAPS)) > + if (nouveau_check_optimus_dsm(dhandle)) > retval |= NOUVEAU_DSM_HAS_OPT; > > if (retval & NOUVEAU_DSM_HAS_OPT) { >
[PATCH] nouveau, ACPI: fix regression caused by b072e53
On 2014/2/19 18:12, Maarten Lankhorst wrote: > op 19-02-14 05:53, Jiang Liu schreef: >> On some platforms, ACPI _DSM method (nouveau_op_dsm_muid, function 0) >> has special requirements on the fourth parameter, which is different >> from ACPI specifications. So revert to the private implementation >> to check availability of _DSM functions instead of using common >> acpi_check_dsm() interface. >> >> Signed-off-by: Jiang Liu >> --- >> Hi Maarten, >> Thanks for bisecting. Could you please help to verify whether >> this patch fixes the regression? >> > Tested-by: Maarten Lankhorst > > I was wrong about the operator precedence, seems correct after all. :-) Hi Maarten, Thanks for testing. Cheers! Gerry
[PATCH] host1x: export host1x_syncpt_incr_max function
From: Bryan Wu Tegra V4L2 camera driver needs this function to do frame capture. Signed-off-by: Bryan Wu --- include/linux/host1x.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/host1x.h b/include/linux/host1x.h index 3af8472..d2b5299 100644 --- a/include/linux/host1x.h +++ b/include/linux/host1x.h @@ -136,6 +136,7 @@ u32 host1x_syncpt_id(struct host1x_syncpt *sp); u32 host1x_syncpt_read_min(struct host1x_syncpt *sp); u32 host1x_syncpt_read_max(struct host1x_syncpt *sp); int host1x_syncpt_incr(struct host1x_syncpt *sp); +u32 host1x_syncpt_incr_max(struct host1x_syncpt *sp, u32 incrs); int host1x_syncpt_wait(struct host1x_syncpt *sp, u32 thresh, long timeout, u32 *value); struct host1x_syncpt *host1x_syncpt_request(struct device *dev, -- 1.8.3.2
[PATCH] host1x: export host1x_syncpt_incr_max function
On Wed, Feb 19, 2014 at 2:24 PM, Stephen Warren wrote: > On 02/19/2014 03:23 PM, Bryan Wu wrote: >> Tegra V4L2 camera driver needs this function to do frame capture. > > Does it need to be EXPORT_SYMBOL()d too, in case things are modules? > Sure, I will update this patch to export symbol of it. Thanks, -Bryan
[PATCH v2] host1x: export host1x_syncpt_incr_max function
From: Bryan Wu Tegra V4L2 camera driver needs this function to do frame capture. Signed-off-by: Bryan Wu --- drivers/gpu/host1x/syncpt.c | 1 + include/linux/host1x.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c index bfb09d8..b10550e 100644 --- a/drivers/gpu/host1x/syncpt.c +++ b/drivers/gpu/host1x/syncpt.c @@ -102,6 +102,7 @@ u32 host1x_syncpt_incr_max(struct host1x_syncpt *sp, u32 incrs) { return (u32)atomic_add_return(incrs, &sp->max_val); } +EXPORT_SYMBOL(host1x_syncpt_incr_max); /* * Write cached syncpoint and waitbase values to hardware. diff --git a/include/linux/host1x.h b/include/linux/host1x.h index 3af8472..d2b5299 100644 --- a/include/linux/host1x.h +++ b/include/linux/host1x.h @@ -136,6 +136,7 @@ u32 host1x_syncpt_id(struct host1x_syncpt *sp); u32 host1x_syncpt_read_min(struct host1x_syncpt *sp); u32 host1x_syncpt_read_max(struct host1x_syncpt *sp); int host1x_syncpt_incr(struct host1x_syncpt *sp); +u32 host1x_syncpt_incr_max(struct host1x_syncpt *sp, u32 incrs); int host1x_syncpt_wait(struct host1x_syncpt *sp, u32 thresh, long timeout, u32 *value); struct host1x_syncpt *host1x_syncpt_request(struct device *dev, -- 1.8.3.2
3.13 i915 brightness settings broken when going from docked -> undocked
Hi All, We've had a rather weird report[1] of the brightness adjustments being broken in a specific case with Thinkpad x220 hardware (SandyBridge based). If you boot the machine with it in a dock and then undock, the brightness adjustments do not work. That is with either the FN keys or the GNOME brightness slider. I can see that the value of /sys/class/backlight/acpi_video0/brightness increases/decreases but /sys/class/backlight/intel_backlight/brightness doesn't reflect any changes. With 3.12 this works, and oddly with 3.14-rc1 it works (specifically, it starts working around v3.13-10231-g53d8ab2 which is right after the first DRM merge for 3.14). With 3.13, if I undock and echo a higher value in the intel_backlight_brightness sysfs entry, the brightness will actually increase so it can be done manually, but it does not work as you'd expect. I'm in the middle of trying to do a reverse bisect for which patch fixes it in the 3.14-rcX series, but that's taking a while. I thought I'd email and see if anyone already knows about this situation, what patch in 3.13 broke this, and which one then fixed it again. Thus far all I've gathered is that backlight handling is confusing. josh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1067071