[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash

2014-02-19 Thread bugzilla-dae...@bugzilla.kernel.org
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

2014-02-19 Thread bugzilla-dae...@bugzilla.kernel.org
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

2014-02-19 Thread bugzilla-dae...@bugzilla.kernel.org
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

2014-02-19 Thread bugzilla-dae...@bugzilla.kernel.org
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

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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

2014-02-19 Thread Boszormenyi Zoltan
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

2014-02-19 Thread Michel Dänzer
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

2014-02-19 Thread Maarten Lankhorst
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

2014-02-19 Thread Sagar Arun Kamble
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-19 Thread Inki Dae
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 Thread Boszormenyi Zoltan
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

2014-02-19 Thread Inki Dae
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

2014-02-19 Thread Ville Syrjälä
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-02-19 Thread Inki Dae
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

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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)

2014-02-19 Thread Maarten Lankhorst
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

2014-02-19 Thread Thomas Hellstrom
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

2014-02-19 Thread Thomas Hellstrom
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

2014-02-19 Thread Thomas Hellstrom
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

2014-02-19 Thread Thomas Hellstrom
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

2014-02-19 Thread Alex Deucher
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)

2014-02-19 Thread bugzilla-dae...@bugzilla.kernel.org
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)

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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

2014-02-19 Thread Thierry Reding
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()

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Thierry Reding
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()

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Thierry Reding
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)

2014-02-19 Thread bugzilla-dae...@bugzilla.kernel.org
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

2014-02-19 Thread bugzilla-dae...@bugzilla.kernel.org
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

2014-02-19 Thread bugzilla-dae...@bugzilla.kernel.org
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

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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)

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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

2014-02-19 Thread Eric Anholt
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()

2014-02-19 Thread Eric Anholt
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)

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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

2014-02-19 Thread Sylvain BERTRAND
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

2014-02-19 Thread Erik Faye-Lund
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

2014-02-19 Thread Rémi Cardona
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

2014-02-19 Thread Erik Faye-Lund
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

2014-02-19 Thread Erik Faye-Lund
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()

2014-02-19 Thread Erik Faye-Lund
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

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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?

2014-02-19 Thread Konrad Rzeszutek Wilk
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()

2014-02-19 Thread Erik Faye-Lund
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

2014-02-19 Thread Erik Faye-Lund
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

2014-02-19 Thread Erik Faye-Lund
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

2014-02-19 Thread Erik Faye-Lund
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

2014-02-19 Thread Thierry Reding
 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

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Thierry Reding
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()

2014-02-19 Thread Erik Faye-Lund
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

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Thierry Reding
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

2014-02-19 Thread Stephen Warren
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

2014-02-19 Thread bugzilla-dae...@freedesktop.org
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

2014-02-19 Thread Alex Deucher
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

2014-02-19 Thread Lin, Mengdong
> -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

2014-02-19 Thread Jiang Liu
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

2014-02-19 Thread Jiang Liu
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

2014-02-19 Thread Jiang Liu


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

2014-02-19 Thread Bryan Wu
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

2014-02-19 Thread Bryan Wu
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

2014-02-19 Thread Bryan Wu
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

2014-02-19 Thread Josh Boyer
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