[PATCH v7 11/17] Documentation: phy: add document for rockchip dp phy

2015-10-27 Thread Heiko Stuebner 
Am Samstag, 24. Oktober 2015, 11:06:37 schrieb Yakir Yang:
> Add dt binding documentation for rockchip display port PHY.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---

phy binding looks nice and easy
Reviewed-by: Heiko Stuebner

[PATCH v7 10/17] phy: Add driver for rockchip Display Port PHY

2015-10-27 Thread Heiko Stuebner 
Am Samstag, 24. Oktober 2015, 11:06:04 schrieb Yakir Yang:
> Add phy driver for the Rockchip DisplayPort PHY module. This
> is required to get DisplayPort working in Rockchip SoCs.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---

> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..4af19af
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,153 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang 
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GRF_SOC_CON12   0x0274
> +#define GRF_EDP_REF_CLK_SEL_INTERBIT(4)
> +#define GRF_EDP_PHY_SIDDQ_WRITE_EN  BIT(21)
> +#define GRF_EDP_PHY_SIDDQ_ON0
> +#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)

mixed spacers (tabs and spaces), please use either tabs if you want to
align stuff or a single space.

Also you're mixing the handling here, for SIDDQ you're defining both the
actual bit as well as the write-enable bit, but for CLK_SEL_INTR you're
hard-coding the 16-bit shift down in the code.

You could also just use/copy the HIWORD_MASK macro we use for example
in the clock controller.


> +
> +struct rockchip_dp_phy {
> + struct device  *dev;
> + struct regmap  *grf;
> + struct clk *phy_24m;
> +};
> +
> +static int rockchip_set_phy_state(struct phy *phy, bool enable)
> +{
> + struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
> + int ret;
> +
> + if (enable) {
> + ret = regmap_write(dp->grf, GRF_SOC_CON12,
> +GRF_EDP_PHY_SIDDQ_WRITE_EN |
> +GRF_EDP_PHY_SIDDQ_ON);
> + if (ret < 0) {
> + dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(dp->phy_24m);
> +

unnecessary empty line after clk_prepare_enable


with these things fixed,
Reviewed-by: Heiko Stuebner 


Cheers,
Heiko

[PATCH v7 09/17] Documentation: drm/bridge: add document for analogix_dp

2015-10-27 Thread Heiko Stuebner 
Patch subject should probably be something like:

dt-bindings: add document for rockchip variant of analogix_dp

or similar, but definitly should mention that it's the Rockchip variant.


Am Samstag, 24. Oktober 2015, 11:06:03 schrieb Yakir Yang:
> Rockchip DP driver is a helper driver of analogix_dp coder driver,
> so most of the DT property should be descriped in analogix_dp document.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 

everything else looks nice, so with a better subject

Reviewed-by: Heiko Stuebner

[PATCH v7 06/17] Documentation: drm/bridge: add document for analogix_dp

2015-10-27 Thread Heiko Stuebner 
Hi Yakir,

Am Samstag, 24. Oktober 2015, 11:06:00 schrieb Yakir Yang:
> Analogix dp driver is split from exynos dp driver, so we just
> make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
> 
> Beside update some exynos dtsi file with the latest change
> according to the devicetree binding documents.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 
> ---
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 7a3a9cd..9e47357 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -31,45 +31,31 @@ Required properties for dp-controller:
>   from general PHY binding: the phandle for the PHY device.
>   -phy-names:
>   from general PHY binding: Should be "dp".
> - -samsung,color-space:
> - input video data format.
> - COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
> - -samsung,dynamic-range:
> - dynamic range for input video data.
> - VESA = 0, CEA = 1
> - -samsung,ycbcr-coeff:
> - YCbCr co-efficients for input video.
> - COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> - -samsung,color-depth:
> - number of bits per colour component.
> - COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> - -samsung,link-rate:
> - link rate supported by the panel.
> - LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
> - -samsung,lane-count:
> - number of lanes supported by the panel.
> - LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> +
> +Optional properties for dp-controller:
>   - display-timings: timings for the connected panel as described by
>   Documentation/devicetree/bindings/video/display-timing.txt

^^

bindings/display/display-timing.txt ... that actually made the patch not apply 
cleanly


[...]

> -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +Deprecated properties for DisplayPort:
> +-interlaced:deprecated prop that can parsed frm drm_display_mode.
> +-vsync-active-high: deprecated prop that can parsed frm drm_display_mode.
> +-hsync-active-high: deprecated prop that can parsed frm drm_display_mode.
> +-samsung,ycbcr-coeff:   deprecated prop that can parsed frm drm_display_mode.
> +-samsung,dynamic-range: deprecated prop that can parsed frm drm_display_mode.

the "frm" above need some more "o"s to be "from"s :-)

> +-samsung,color-space:   deprecated prop that can parsed from 
> drm_display_info.
> +-samsung,color-depth:   deprecated prop that can parsed from 
> drm_display_info.
> +-samsung,link-rate: deprecated prop that can reading from monitor by 
> dpcd method.
> +-samsung,lane-count:deprecated prop that can reading from monitor by 
> dpcd method.
> +-samsung,hpd-gpio:  deprecated name for hpd-gpios.
> +
> +---


Cheers,
Heiko

No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c

2015-10-27 Thread Michel Dänzer 
On 27.10.2015 17:44, Michael Burian wrote:
> On 10/27/15 03:36, Michel Dänzer wrote:
>>>
>>> [0] contains dmesg output with your patch applied (which fixes the 
>>> backlight issue)
>>
>> This is very surprising: The patch just adds some debugging output, it's
>> not supposed to have any functional effect. Also, I don't see any of the
>> debugging output added by the patch in
>> dmesg-4.3.0-rc7-3-g85051e2-dirty-2015-10-26-11-00-41-radeon-bl-debug.
>>
> 
>> Are you sure that my patch was actually applied to the radeon driver
>> when generating that file? Did you update the initrd with the patched
>> radeon.ko?
>>
> 
> the build was done using "make -j4 deb-pkg" on a better equipped machine,
> .deb packages were copied over and installed - maybe something interesting
> happened
> 
> AFAICT the patch should have been applied, at least it was shown with
> git diff and the -dirty suffix was added by the build system, not me.
> All graphics related drivers are compiled in (=y) rather than as
> modules (=m) in .config.
> 
> Another thing I tried yesterday was to add the old way right below the new one
> (this fixes the backlight issue) enclosed by some debug statements that 
> indicate
> start / stop of the old / new method. (see atomdebug.diff - should be applied 
> against
> mainline)

I'm not familiar with the ATOM bytecode, but since the number of
bytecode instructions executed seems the same in both cases, I suspect
that dig->backlight_level == 0 => ATOM_LCD_BLOFF is executed. (The
debugging output in my patch would have provided all of this information
and more, but there wasn't any of it in the dmesg you provided)

I guess the question then becomes how dig->backlight_level is (supposed
to be) initialized.

What values do the following files contain in the broken and working cases?

/sys/class/backlight/radeon_bl0/bl_power
/sys/class/backlight/radeon_bl0/brightness
/sys/class/backlight/radeon_bl0/actual_brightness
/sys/class/backlight/radeon_bl0/max_brightness


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

No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c

2015-10-27 Thread Michael Burian 
On 10/27/15 17:43, Alex Deucher wrote:
> 
> I see the problem.  We don't enable native backlight control on older
> asics like yours by default.  Does the attached patch help?
> 

Yes, backlight is on again. (tested against mainline: 
858e904bd71dd0057a548d6785d94ce5ec4aeabd)

thanks

No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c

2015-10-27 Thread Michael Burian 
On 10/27/15 16:10, Alex Deucher wrote:

> 
> It would appear that your system does not use the gpu backlight
> controller.  Either it's lying or messing with the GPU backlight
> controller causes some bad interaction with whatever does control it.
> Does the attached radeon patch help?  I'm also attaching an amdgpu
> patch for reference in case the same problem appears on amdgpu.
> 

no, still no backlight when applied against current current mainline

858e904bd71dd0057a548d6785d94ce5ec4aeabd (Merge tag 'iommu-fixes-v4.3-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)

[Bug 91917] linux-firmware.git should carry most recent firmware for SI, CI et al.

2015-10-27 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=91917

Kai  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #1 from Kai  ---
Ping.

There has been a further round of firmware updates on 2015-10-16.

-- 
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/20151027/572dc1b2/attachment.html>

[PATCH 2/2] drm/amdgpu: switch to common fence_wait_any_timeout v2

2015-10-27 Thread Christian König 
From: Christian König 

No need to duplicate the functionality any more.

v2: fix handling if no fence is available.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher  (v1)
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  4 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 98 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c| 20 ---
 3 files changed, 13 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index a9c0def..dd7d2ce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -447,10 +447,6 @@ int amdgpu_fence_wait_next(struct amdgpu_ring *ring);
 int amdgpu_fence_wait_empty(struct amdgpu_ring *ring);
 unsigned amdgpu_fence_count_emitted(struct amdgpu_ring *ring);

-signed long amdgpu_fence_wait_any(struct fence **array,
- uint32_t count,
- bool intr,
- signed long t);
 struct amdgpu_fence *amdgpu_fence_ref(struct amdgpu_fence *fence);
 void amdgpu_fence_unref(struct amdgpu_fence **fence);

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 663caa9..c4bb282 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
@@ -822,104 +822,6 @@ static const char *amdgpu_fence_get_timeline_name(struct 
fence *f)
return (const char *)fence->ring->name;
 }

-static bool amdgpu_test_signaled_any(struct fence **fences, uint32_t count)
-{
-   int idx;
-   struct fence *fence;
-
-   for (idx = 0; idx < count; ++idx) {
-   fence = fences[idx];
-   if (fence) {
-   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
-   return true;
-   }
-   }
-   return false;
-}
-
-struct amdgpu_wait_cb {
-   struct fence_cb base;
-   struct task_struct *task;
-};
-
-static void amdgpu_fence_wait_cb(struct fence *fence, struct fence_cb *cb)
-{
-   struct amdgpu_wait_cb *wait =
-   container_of(cb, struct amdgpu_wait_cb, base);
-   wake_up_process(wait->task);
-}
-
-/**
- * Wait the fence array with timeout
- *
- * @array:the fence array with amdgpu fence pointer
- * @count:the number of the fence array
- * @intr: when sleep, set the current task interruptable or not
- * @t:timeout to wait
- *
- * It will return when any fence is signaled or timeout.
- */
-signed long amdgpu_fence_wait_any(struct fence **array, uint32_t count,
- bool intr, signed long t)
-{
-   struct amdgpu_wait_cb *cb;
-   struct fence *fence;
-   unsigned idx;
-
-   BUG_ON(!array);
-
-   cb = kcalloc(count, sizeof(struct amdgpu_wait_cb), GFP_KERNEL);
-   if (cb == NULL) {
-   t = -ENOMEM;
-   goto err_free_cb;
-   }
-
-   for (idx = 0; idx < count; ++idx) {
-   fence = array[idx];
-   if (fence) {
-   cb[idx].task = current;
-   if (fence_add_callback(fence,
-   [idx].base, amdgpu_fence_wait_cb)) {
-   /* The fence is already signaled */
-   goto fence_rm_cb;
-   }
-   }
-   }
-
-   while (t > 0) {
-   if (intr)
-   set_current_state(TASK_INTERRUPTIBLE);
-   else
-   set_current_state(TASK_UNINTERRUPTIBLE);
-
-   /*
-* amdgpu_test_signaled_any must be called after
-* set_current_state to prevent a race with wake_up_process
-*/
-   if (amdgpu_test_signaled_any(array, count))
-   break;
-
-   t = schedule_timeout(t);
-
-   if (t > 0 && intr && signal_pending(current))
-   t = -ERESTARTSYS;
-   }
-
-   __set_current_state(TASK_RUNNING);
-
-fence_rm_cb:
-   for (idx = 0; idx < count; ++idx) {
-   fence = array[idx];
-   if (fence && cb[idx].base.func)
-   fence_remove_callback(fence, [idx].base);
-   }
-
-err_free_cb:
-   kfree(cb);
-
-   return t;
-}
-
 const struct fence_ops amdgpu_fence_ops = {
.get_driver_name = amdgpu_fence_get_driver_name,
.get_timeline_name = amdgpu_fence_get_timeline_name,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
index 5cb27d5..3f48759 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
@@ -337,6 +337,7 @@ int amdgpu_sa_bo_new(struct amdgpu_device *adev,
 {
struct fence *fences[AMDGPU_MAX_RINGS];
unsigned tries[AMDGPU_MAX_RINGS];
+   unsigned count;

[PATCH 1/2] dma-buf/fence: add fence_wait_any_timeout function v2

2015-10-27 Thread Christian König 
From: Christian König 

Waiting for the first fence in an array of fences to signal.

This is useful for device driver specific resource managers
and also Vulkan needs something similar.

v2: more parameter checks, handling for timeout==0,
remove NULL entry support, better callback removal.

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
---
 drivers/dma-buf/fence.c | 98 +
 include/linux/fence.h   |  3 +-
 2 files changed, 100 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
index 50ef8bd..7b05dbe 100644
--- a/drivers/dma-buf/fence.c
+++ b/drivers/dma-buf/fence.c
@@ -397,6 +397,104 @@ out:
 }
 EXPORT_SYMBOL(fence_default_wait);

+static bool
+fence_test_signaled_any(struct fence **fences, uint32_t count)
+{
+   int i;
+
+   for (i = 0; i < count; ++i) {
+   struct fence *fence = fences[i];
+   if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
+   return true;
+   }
+   return false;
+}
+
+/**
+ * fence_wait_any_timeout - sleep until any fence gets signaled
+ * or until timeout elapses
+ * @fences:[in]array of fences to wait on
+ * @count: [in]number of fences to wait on
+ * @intr:  [in]if true, do an interruptible wait
+ * @timeout:   [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
+ *
+ * Returns -EINVAL on custom fence wait implementation, -ERESTARTSYS if
+ * interrupted, 0 if the wait timed out, or the remaining timeout in jiffies
+ * on success.
+ *
+ * Synchronous waits for the first fence in the array to be signaled. The
+ * caller needs to hold a reference to all fences in the array, otherwise a
+ * fence might be freed before return, resulting in undefined behavior.
+ */
+signed long
+fence_wait_any_timeout(struct fence **fences, uint32_t count,
+  bool intr, signed long timeout)
+{
+   struct default_wait_cb *cb;
+   signed long ret = timeout;
+   unsigned i;
+
+   if (WARN_ON(!fences || !count || timeout < 0))
+   return -EINVAL;
+
+   if (timeout == 0) {
+   for (i = 0; i < count; ++i)
+   if (fence_is_signaled(fences[i]))
+   return 1;
+
+   return 0;
+   }
+
+   cb = kcalloc(count, sizeof(struct default_wait_cb), GFP_KERNEL);
+   if (cb == NULL) {
+   ret = -ENOMEM;
+   goto err_free_cb;
+   }
+
+   for (i = 0; i < count; ++i) {
+   struct fence *fence = fences[i];
+
+   if (fence->ops->wait != fence_default_wait) {
+   ret = -EINVAL;
+   goto fence_rm_cb;
+   }
+
+   cb[i].task = current;
+   if (fence_add_callback(fence, [i].base,
+  fence_default_wait_cb)) {
+   /* This fence is already signaled */
+   goto fence_rm_cb;
+   }
+   }
+
+   while (ret > 0) {
+   if (intr)
+   set_current_state(TASK_INTERRUPTIBLE);
+   else
+   set_current_state(TASK_UNINTERRUPTIBLE);
+
+   if (fence_test_signaled_any(fences, count))
+   break;
+
+   ret = schedule_timeout(ret);
+
+   if (ret > 0 && intr && signal_pending(current))
+   ret = -ERESTARTSYS;
+   }
+
+   __set_current_state(TASK_RUNNING);
+
+fence_rm_cb:
+   while (i-- > 0)
+   fence_remove_callback(fences[i], [i].base);
+
+err_free_cb:
+   kfree(cb);
+
+   return ret;
+}
+EXPORT_SYMBOL(fence_wait_any_timeout);
+
 /**
  * fence_init - Initialize a custom fence.
  * @fence: [in]the fence to initialize
diff --git a/include/linux/fence.h b/include/linux/fence.h
index ddc0f26..bb52201 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -321,7 +321,8 @@ static inline struct fence *fence_later(struct fence *f1, 
struct fence *f2)
 }

 signed long fence_wait_timeout(struct fence *, bool intr, signed long timeout);
-
+signed long fence_wait_any_timeout(struct fence **fences, uint32_t count,
+  bool intr, signed long timeout);

 /**
  * fence_wait - sleep until the fence gets signaled
-- 
1.9.1

Missing amdgpu firmware files

2015-10-27 Thread Christian König 
Well that's strange. Essentially those are just duplicates to the 
existing files and the driver should fallback to them.

IIRC the radeon/*_sdma1.bin files are only requested when you try to use 
CIK support with amdgpu which isn't a good idea in a production environment.

What's the link for the bug reports? It's most likely just people trying 
to use the driver with hardware which it isn't supposed to be used with.

We probably should either remove CIK support totally from the amdgpu or 
add all the files to the firmware repository.

Regards,
Christian.

On 27.10.2015 16:42, Seth Forshee wrote:
> I've received reports from Ubuntu users about missing amdgpu firmware
> files with 4.2 kernels. The driver calls out a number of
> radeon/*_sdma1.bin files that are not present in the linux-firmware git
> repo. Are these files available anywhere (under a license that allows
> redistribution), and will they be pushed up to linux-firmware anytime
> soon?
>
> Thanks,
> Seth
>

Missing amdgpu firmware files

2015-10-27 Thread Deucher, Alexander 
> -Original Message-
> From: Seth Forshee [mailto:seth.forshee at canonical.com]
> Sent: Tuesday, October 27, 2015 12:06 PM
> To: Koenig, Christian
> Cc: Deucher, Alexander; Oded Gabbay; dri-devel at lists.freedesktop.org
> Subject: Re: Missing amdgpu firmware files
> 
> On Tue, Oct 27, 2015 at 04:47:53PM +0100, Christian König wrote:
> > Well that's strange. Essentially those are just duplicates to the
> > existing files and the driver should fallback to them.
> >
> > IIRC the radeon/*_sdma1.bin files are only requested when you try to
> > use CIK support with amdgpu which isn't a good idea in a production
> > environment.
> >
> > What's the link for the bug reports? It's most likely just people
> > trying to use the driver with hardware which it isn't supposed to be
> > used with.
> 
> There have been a few reports that the firmware is missing, but only one
> I see where the user actually reports any display problems.
> 
>  http://bugs.launchpad.net/bugs/1510405
> 
> Of course it's possible that he is jumping to conclusions about the
> missing firmware files causing his display issues.

The driver refuses to load if the firmware is missing.  However, as Christian 
mentioned, you will only get those messages if you've enabled CIK support 
amdgpu which we don't recommend (controlled by CONFIG_DRM_AMDGPU_CIK).  Radeon 
does not require the additional firmware.

Alex

[Bug 106291] amdgpu fails GPU reset when resuming from suspend

2015-10-27 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=106291

--- Comment #8 from universaledge97 at gmail.com ---
It turned out that the amdgpu kernel module was not included in compilation. I
normally use the linux-mainline package from the AUR (I run Arch Linux) to
install rc kernels, where, for some reason, the amdgpu module was not enabled
to compile by default. I now have amdgpu built into 4.3rc7, and will report
back if the issue is still present.

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

Missing amdgpu firmware files

2015-10-27 Thread Deucher, Alexander 
> -Original Message-
> From: Koenig, Christian
> Sent: Tuesday, October 27, 2015 11:48 AM
> To: Seth Forshee; Deucher, Alexander; Oded Gabbay
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: Missing amdgpu firmware files
> 
> Well that's strange. Essentially those are just duplicates to the
> existing files and the driver should fallback to them.
> 
> IIRC the radeon/*_sdma1.bin files are only requested when you try to use
> CIK support with amdgpu which isn't a good idea in a production
> environment.
> 
> What's the link for the bug reports? It's most likely just people trying
> to use the driver with hardware which it isn't supposed to be used with.
> 
> We probably should either remove CIK support totally from the amdgpu or
> add all the files to the firmware repository.

Exactly.  They are only used if you forcibly enable CIK support in amdgpu which 
is just for testing.  CIK is already supported in radeon and that should be 
used for CIK parts.  Sdma1 is identical to regular sdma file so you can just 
symlink them or copy them.  I guess I can update the firmware tree.

Alex


> 
> Regards,
> Christian.
> 
> On 27.10.2015 16:42, Seth Forshee wrote:
> > I've received reports from Ubuntu users about missing amdgpu firmware
> > files with 4.2 kernels. The driver calls out a number of
> > radeon/*_sdma1.bin files that are not present in the linux-firmware git
> > repo. Are these files available anywhere (under a license that allows
> > redistribution), and will they be pushed up to linux-firmware anytime
> > soon?
> >
> > Thanks,
> > Seth
> >

[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

2015-10-27 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=106271

--- Comment #6 from Alex Deucher  ---
(In reply to Aneroid from comment #5)
> Yes, I try to do that.
> 
> xrandr --listproviders
> Providers: number : 2
> Provider 0: id: 0x7e cap: 0xf, Source Output, Sink Output, Source Offload,
> Sink Offload crtcs: 4 outputs: 4 associated providers: 0 name:radeon
> Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload,
> Sink Offload crtcs: 6 outputs: 1 associated providers: 0 name:radeon
> 
> xrandr --setprovideroffloadsink 0x7e 0x46

You've got the arguments reversed; the first is the offload device, the second
is the display device.  Try:

xrandr --setprovideroffloadsink 0x46 0x7e

> 
> And it ruined my xorg completely. X fall out in to the shell without any
> errors.

Can you attach your dmesg output and xorg log when you do that?

Does adding amdgpu.runpm=0 to the kernel command line in grub help?

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

[PATCH v11 2/4] PM / Domains: add setter for dev.pm_domain

2015-10-27 Thread Tomeu Vizoso 
Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.

This patch also changes all current code that directly sets the
dev.pm_domain pointer.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Ulf Hansson 
---

Changes in v11:
- Move calls to dev_pm_domain_set() out from >power.lock as that
  isn't needed for dev->pm_domain.

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()

Changes in v8:
- Add dev_pm_domain_set() and update code to use it

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 21 +
 drivers/base/power/domain.c   |  6 --
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 include/linux/pm_domain.h |  3 +++
 10 files changed, 52 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c 
b/arch/arm/mach-omap2/omap_device.c
index 4cb8fd9f741f..204101d11632 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -168,7 +169,7 @@ static int omap_device_build_from_dt(struct platform_device 
*pdev)
r->name = dev_name(>dev);
}

-   pdev->dev.pm_domain = _device_pm_domain;
+   dev_pm_domain_set(>dev, _device_pm_domain);

if (device_active) {
omap_device_enable(pdev);
@@ -180,7 +181,7 @@ odbfd_exit1:
 odbfd_exit:
/* if data/we are at fault.. load up a fail handler */
if (ret)
-   pdev->dev.pm_domain = _device_fail_pm_domain;
+   dev_pm_domain_set(>dev, _device_fail_pm_domain);

return ret;
 }
@@ -701,7 +702,7 @@ int omap_device_register(struct platform_device *pdev)
 {
pr_debug("omap_device: %s: registering\n", pdev->name);

-   pdev->dev.pm_domain = _device_pm_domain;
+   dev_pm_domain_set(>dev, _device_pm_domain);
return platform_device_add(pdev);
 }

diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index f51bd0d0bc17..cc6e1abc69b3 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 

@@ -706,7 +707,7 @@ static int acpi_lpss_platform_notify(struct notifier_block 
*nb,

switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
-   pdev->dev.pm_domain = _lpss_pm_domain;
+   dev_pm_domain_set(>dev, _lpss_pm_domain);
if (pdata->dev_desc->flags & LPSS_LTR)
return sysfs_create_group(>dev.kobj,
  _attr_group);
@@ -714,7 +715,7 @@ static int acpi_lpss_platform_notify(struct notifier_block 
*nb,
case BUS_NOTIFY_DEL_DEVICE:
if (pdata->dev_desc->flags & LPSS_LTR)
sysfs_remove_group(>dev.kobj, _attr_group);
-   pdev->dev.pm_domain = NULL;
+   dev_pm_domain_set(>dev, NULL);
break;
default:
break;
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 4806b7f856c4..8c5955bf9bbf 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #include "internal.h"
@@ -1076,7 +1077,7 @@ static void acpi_dev_pm_detach(struct device *dev, bool 
power_off)
struct acpi_device *adev = ACPI_COMPANION(dev);

if (adev && dev->pm_domain == _general_pm_domain) {
-   dev->pm_domain = NULL;
+   dev_pm_domain_set(dev, NULL);
acpi_remove_pm_notifier(adev);
if (power_off) {
/*
@@ -1128,7 +1129,7 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on)
return -EBUSY;

acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
-   dev->pm_domain = _general_pm_domain;
+   dev_pm_domain_set(dev, _general_pm_domain);
if (power_on) {
acpi_dev_pm_full_power(adev);
acpi_device_wakeup(adev, ACPI_STATE_S0, false);
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 652b5a367c1f..e80fda6c03a9 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 #ifdef CONFIG_PM
@@ -346,7 +347,7 @@ static int pm_clk_notify(struct notifier_block *nb,

[PATCH v11 0/4] Allow USB devices to remain runtime-suspended when sleeping

2015-10-27 Thread Tomeu Vizoso 
Hi,

this is v11 of an attempt to make it easier for devices to remain in
runtime PM when the system goes to sleep, mainly to reduce the time
spent resuming devices.

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

With these changes, a uvcvideo device (for example) stays in runtime
suspend when the system goes to sleep and is left in that state when the
system resumes, not delaying it unnecessarily.

Thanks,

Tomeu

Changes in v11:
- Move calls to dev_pm_domain_set() out from >power.lock as that
  isn't needed for dev->pm_domain.

Changes in v10:
- Remove superfluous call to pm_runtime_enabled() as suggested by Alan

Changes in v9:
- Add docs noting the need for the device lock to be held before calling
  device_is_bound()
- Add docs noting the need for the device lock to be held before calling
  dev_pm_domain_set()
- Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf.
- Rename from device_check_pm_callbacks to device_pm_check_callbacks to
  follow with the naming convention of existing API.
- Re-add calling to device_pm_check_callbacks from device registration
  and when updating the PM domain of a device.

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 21 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   | 24 
 drivers/base/power/domain.c   |  8 ++--
 drivers/base/power/main.c | 35 +++
 drivers/base/power/power.h|  3 +++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c|  8 +++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 130 insertions(+), 23 deletions(-)

-- 
2.5.0

[Bug 106271] Switch between AMD hybrid graphics (HD 8650G / HD 8970M) makes hardware reset.

2015-10-27 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=106271

--- Comment #5 from Aneroid  ---
Yes, I try to do that.

xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7e cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 4 outputs: 4 associated providers: 0 name:radeon
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 6 outputs: 1 associated providers: 0 name:radeon

xrandr --setprovideroffloadsink 0x7e 0x46

And it ruined my xorg completely. X fall out in to the shell without any
errors.

I could switch between graphics card on flgrx driver with "aticonfig --px-dgpu"
and "aticonfig --px-igpu". It worked well.
But now, it seems that I stuck in low power graphics mode and I can't switch to
my power card. '

glxinfo always show me AMD ARUBA chip:

glxinfo | grep "OpenGL renderer"
OpenGL renderer string: Gallium 0.4 on AMD ARUBA (DRM 2.43.0, LLVM 3.7.0)

DRI_PRIME=1 glxinfo | grep "OpenGL renderer"
OpenGL renderer string: Gallium 0.4 on AMD ARUBA (DRM 2.43.0, LLVM 3.7.0)

DRI_PRIME=0 glxinfo | grep "OpenGL renderer"
OpenGL renderer string: Gallium 0.4 on AMD ARUBA (DRM 2.43.0, LLVM 3.7.0)

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

[PATCH v3 3/3] drm/tegra: Remove local fbdev emulation Kconfig option

2015-10-27 Thread Archit Taneja 
DRM_TEGRA_FBDEV config is currently used to enable/disable legacy fbdev
emulation for the tegra kms driver.

Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option instead.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/tegra/Kconfig | 12 
 drivers/gpu/drm/tegra/drm.c   |  4 ++--
 drivers/gpu/drm/tegra/drm.h   |  6 +++---
 drivers/gpu/drm/tegra/fb.c| 12 ++--
 4 files changed, 11 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 74d9d62..63ebb15 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -16,18 +16,6 @@ config DRM_TEGRA

 if DRM_TEGRA

-config DRM_TEGRA_FBDEV
-   bool "Enable legacy fbdev support"
-   select DRM_KMS_FB_HELPER
-   select FB_SYS_FILLRECT
-   select FB_SYS_COPYAREA
-   select FB_SYS_IMAGEBLIT
-   default y
-   help
- Choose this option if you have a need for the legacy fbdev support.
- Note that this support also provides the Linux console on top of
- the Tegra modesetting driver.
-
 config DRM_TEGRA_DEBUG
bool "NVIDIA Tegra DRM debug support"
help
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 159ef51..e0f8277 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -106,7 +106,7 @@ static int tegra_atomic_commit(struct drm_device *drm,

 static const struct drm_mode_config_funcs tegra_drm_mode_funcs = {
.fb_create = tegra_fb_create,
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
.output_poll_changed = tegra_fb_output_poll_changed,
 #endif
.atomic_check = drm_atomic_helper_check,
@@ -260,7 +260,7 @@ static void tegra_drm_context_free(struct tegra_drm_context 
*context)

 static void tegra_drm_lastclose(struct drm_device *drm)
 {
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct tegra_drm *tegra = drm->dev_private;

tegra_fbdev_restore_mode(tegra->fbdev);
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index ec49275..942cad9 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -30,7 +30,7 @@ struct tegra_fb {
unsigned int num_planes;
 };

-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
 struct tegra_fbdev {
struct drm_fb_helper base;
struct tegra_fb *fb;
@@ -46,7 +46,7 @@ struct tegra_drm {
struct mutex clients_lock;
struct list_head clients;

-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct tegra_fbdev *fbdev;
 #endif

@@ -273,7 +273,7 @@ int tegra_drm_fb_prepare(struct drm_device *drm);
 void tegra_drm_fb_free(struct drm_device *drm);
 int tegra_drm_fb_init(struct drm_device *drm);
 void tegra_drm_fb_exit(struct drm_device *drm);
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
 void tegra_fbdev_restore_mode(struct tegra_fbdev *fbdev);
 void tegra_fb_output_poll_changed(struct drm_device *drm);
 #endif
diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 07c844b..9b8aa96 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -18,7 +18,7 @@ static inline struct tegra_fb *to_tegra_fb(struct 
drm_framebuffer *fb)
return container_of(fb, struct tegra_fb, base);
 }

-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
 static inline struct tegra_fbdev *to_tegra_fbdev(struct drm_fb_helper *helper)
 {
return container_of(helper, struct tegra_fbdev, base);
@@ -181,7 +181,7 @@ unreference:
return ERR_PTR(err);
 }

-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
 static struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
.fb_fillrect = drm_fb_helper_sys_fillrect,
@@ -371,7 +371,7 @@ void tegra_fb_output_poll_changed(struct drm_device *drm)

 int tegra_drm_fb_prepare(struct drm_device *drm)
 {
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct tegra_drm *tegra = drm->dev_private;

tegra->fbdev = tegra_fbdev_create(drm);
@@ -384,7 +384,7 @@ int tegra_drm_fb_prepare(struct drm_device *drm)

 void tegra_drm_fb_free(struct drm_device *drm)
 {
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct tegra_drm *tegra = drm->dev_private;

tegra_fbdev_free(tegra->fbdev);
@@ -393,7 +393,7 @@ void tegra_drm_fb_free(struct drm_device *drm)

 int tegra_drm_fb_init(struct drm_device *drm)
 {
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct tegra_drm *tegra = drm->dev_private;
int err;

@@ -408,7 +408,7 @@ int tegra_drm_fb_init(struct drm_device *drm)

 void tegra_drm_fb_exit(struct drm_device *drm)
 {
-#ifdef CONFIG_DRM_TEGRA_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
struct tegra_drm *tegra = drm->dev_private;

tegra_fbdev_exit(tegra->fbdev);
-- 
The Qualcomm

[PATCH v3 2/3] drm/sti: Remove local fbdev emulation Kconfig option

2015-10-27 Thread Archit Taneja 
DRM_STI_FBDEV config is currently used to enable/disable fbdev emulation
for the sti kms driver.

Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option instead where applicable.

We replace the #ifdef in sti_drm_load with CONFIG_DRM_FBDEV_EMULATION.
It's probably okay to get remove the #ifdef itself, but just left it here
for now to be safe. It can be removed after some testing.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/sti/Kconfig   | 6 --
 drivers/gpu/drm/sti/sti_drv.c | 2 +-
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index fbccc10..e3aa5af 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -9,9 +9,3 @@ config DRM_STI
select FW_LOADER_USER_HELPER_FALLBACK
help
  Choose this option to enable DRM on STM stiH41x chipset
-
-config DRM_STI_FBDEV
-   bool "DRM frame buffer device for STMicroelectronics SoC stiH41x Serie"
-   depends on DRM_STI
-   help
- Choose this option to enable FBDEV on top of DRM for STM stiH41x 
chipset
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index f846996..1b2db6c 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -160,7 +160,7 @@ static int sti_load(struct drm_device *dev, unsigned long 
flags)

drm_mode_config_reset(dev);

-#ifdef CONFIG_DRM_STI_FBDEV
+#ifdef CONFIG_DRM_FBDEV_EMULATION
drm_fbdev_cma_init(dev, 32,
   dev->mode_config.num_crtc,
   dev->mode_config.num_connector);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v3 1/3] drm/imx: Remove local fbdev emulation Kconfig option

2015-10-27 Thread Archit Taneja 
DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev
emulation for the imx kms driver.

Remove this local config option and use the top level DRM_FBDEV_EMULATION
config option where applicable. Using this config lets us also prevent
wrapping around drm_fb_helper_* calls with #ifdefs in certain places.

Tested-by: Philipp Zabel 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/imx/Kconfig|  9 -
 drivers/gpu/drm/imx/imx-drm-core.c | 12 +++-
 2 files changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 2b81a41..35ca4f0 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -10,15 +10,6 @@ config DRM_IMX
help
  enable i.MX graphics support

-config DRM_IMX_FB_HELPER
-   tristate "provide legacy framebuffer /dev/fb0"
-   select DRM_KMS_CMA_HELPER
-   depends on DRM_IMX
-   help
- The DRM framework can provide a legacy /dev/fb0 framebuffer
- for your device. This is necessary to get a framebuffer console
- and also for applications using the legacy framebuffer API
-
 config DRM_IMX_PARALLEL_DISPLAY
tristate "Support for parallel displays"
select DRM_PANEL
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index de00a6c..cacf2dd 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -49,8 +49,10 @@ struct imx_drm_crtc {
struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
 };

+#if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION)
 static int legacyfb_depth = 16;
 module_param(legacyfb_depth, int, 0444);
+#endif

 int imx_drm_crtc_id(struct imx_drm_crtc *crtc)
 {
@@ -60,26 +62,20 @@ EXPORT_SYMBOL_GPL(imx_drm_crtc_id);

 static void imx_drm_driver_lastclose(struct drm_device *drm)
 {
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm->dev_private;

if (imxdrm->fbhelper)
drm_fbdev_cma_restore_mode(imxdrm->fbhelper);
-#endif
 }

 static int imx_drm_driver_unload(struct drm_device *drm)
 {
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm->dev_private;
-#endif

drm_kms_helper_poll_fini(drm);

-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
if (imxdrm->fbhelper)
drm_fbdev_cma_fini(imxdrm->fbhelper);
-#endif

component_unbind_all(drm->dev, drm);

@@ -215,11 +211,9 @@ EXPORT_SYMBOL_GPL(imx_drm_encoder_destroy);

 static void imx_drm_output_poll_changed(struct drm_device *drm)
 {
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
struct imx_drm_device *imxdrm = drm->dev_private;

drm_fbdev_cma_hotplug_event(imxdrm->fbhelper);
-#endif
 }

 static struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
@@ -308,7 +302,7 @@ static int imx_drm_driver_load(struct drm_device *drm, 
unsigned long flags)
 * The fb helper takes copies of key hardware information, so the
 * crtcs/connectors/encoders must not change after this point.
 */
-#if IS_ENABLED(CONFIG_DRM_IMX_FB_HELPER)
+#if IS_ENABLED(CONFIG_DRM_FBDEV_EMULATION)
if (legacyfb_depth != 16 && legacyfb_depth != 32) {
dev_warn(drm->dev, "Invalid legacyfb_depth.  Defaulting to 
16bpp\n");
legacyfb_depth = 16;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v3 0/3] drm: fb emulation: Remove remaining driver level fb emulation configs

2015-10-27 Thread Archit Taneja 
Instead of using a custom legacy fbdev emulation config option, use the
top level DRM_FBDEV_EMULATION config option.

There are 3 drivers which use custom config options: imx, sti and tegra.
Since the last revision, i915 and msm drivers have removed their custom
configs.

Remove the remaining config options in order to have a single config
option.

Archit Taneja (3):
  drm/imx: Remove local fbdev emulation Kconfig option
  drm/sti: Remove local fbdev emulation Kconfig option
  drm/tegra: Remove local fbdev emulation Kconfig option

 drivers/gpu/drm/imx/Kconfig|  9 -
 drivers/gpu/drm/imx/imx-drm-core.c | 12 +++-
 drivers/gpu/drm/sti/Kconfig|  6 --
 drivers/gpu/drm/sti/sti_drv.c  |  2 +-
 drivers/gpu/drm/tegra/Kconfig  | 12 
 drivers/gpu/drm/tegra/drm.c|  4 ++--
 drivers/gpu/drm/tegra/drm.h|  6 +++---
 drivers/gpu/drm/tegra/fb.c | 12 ++--
 8 files changed, 15 insertions(+), 48 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c

2015-10-27 Thread Alex Deucher 
On Tue, Oct 27, 2015 at 12:23 PM, Michael Burian  
wrote:
> On 10/27/15 16:10, Alex Deucher wrote:
>
>>
>> It would appear that your system does not use the gpu backlight
>> controller.  Either it's lying or messing with the GPU backlight
>> controller causes some bad interaction with whatever does control it.
>> Does the attached radeon patch help?  I'm also attaching an amdgpu
>> patch for reference in case the same problem appears on amdgpu.
>>
>
> no, still no backlight when applied against current current mainline
>
> 858e904bd71dd0057a548d6785d94ce5ec4aeabd (Merge tag 'iommu-fixes-v4.3-rc7' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu)
>

I see the problem.  We don't enable native backlight control on older
asics like yours by default.  Does the attached patch help?

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-dpms-when-driver-backlight-control-is.patch
Type: text/x-patch
Size: 2351 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/7192775b/attachment-0001.bin>

[PATCH 46/48] staging: etnaviv: rewrite submit interface to use copy from user

2015-10-27 Thread Lucas Stach 
Am Montag, den 26.10.2015, 20:48 + schrieb Russell King - ARM Linux:
> On Fri, Sep 25, 2015 at 01:57:58PM +0200, Lucas Stach wrote:
> > +void etnaviv_gpu_cmdbuf_free(struct etnaviv_cmdbuf *cmdbuf)
> > +{
> > +   dma_free_writecombine(cmdbuf->gpu->dev, cmdbuf->size,
> > + cmdbuf->vaddr, cmdbuf->paddr);
> > +   kfree(cmdbuf);
> > +}
> ...
> > @@ -885,6 +914,14 @@ static void retire_worker(struct work_struct *work)
> > +   list_for_each_entry_safe(cmdbuf, tmp, >active_cmd_list,
> > +gpu_active_list) {
> > +   if (fence_after_eq(fence, cmdbuf->fence)) {
> > +   etnaviv_gpu_cmdbuf_free(cmdbuf);
> > +   list_del(>gpu_active_list);
> 
> I mentioned that I'd left one of my machines on a soak test - with vlc
> running with a video clip, but in pause mode.  vlc continues writing
> frames to the etnaviv Xv GPU backend, thereby exercising these code
> paths.  After about 39 hours, the above provoked the oops below, which
> is a use-after-free bug.  Fix on its way to my git branch once builds
> and reboots are complete.
> 
Urgh, thanks for fixing that.

Regards,
Lucas

-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c

2015-10-27 Thread Michel Dänzer 

Michael, please keep the Cc: list intact.


On 26.10.2015 19:46, Michael Burian wrote:
> On 10/26/15 10:32, Michel Dänzer wrote:
>> On 25.10.2015 04:25, Michael Burian wrote:
>>>
>>> # first bad commit: [5a633828b4b2bef343826afcb0a70770c4911c55] drm/radeon: 
>>> Restore LCD backlight level on resume (>= R5xx)
>>>
>>> Workaround 2:
>>>
>>> reverting this single commit 5a633828b4b2bef343826afcb0a70770c4911c55 fixes 
>>> the problem in linux-stable[0]
>>> as well as mainline[1] 4.3.0-rc6-00277-g01815536
>>
>> Please provide the dmesg output from running with the attached debugging
>> patch.
>>
> 
> [0] contains dmesg output with your patch applied (which fixes the backlight 
> issue)

This is very surprising: The patch just adds some debugging output, it's
not supposed to have any functional effect. Also, I don't see any of the
debugging output added by the patch in
dmesg-4.3.0-rc7-3-g85051e2-dirty-2015-10-26-11-00-41-radeon-bl-debug.

Are you sure that my patch was actually applied to the radeon driver
when generating that file? Did you update the initrd with the patched
radeon.ko?


> [1] contains dmesg output without your patch for comparison (resulting in a 
> permanent black screen as before in rc6)
> 
> 
> [0]
> dmesg-4.3.0-rc7-3-g85051e2-dirty-2015-10-26-11-00-41-radeon-bl-debug
> 
> [1]
> dmesg-4.3.0-rc7-3-g85051e2-2015-10-26-11-22-09
> 
> 




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

Missing amdgpu firmware files

2015-10-27 Thread Seth Forshee 
On Tue, Oct 27, 2015 at 04:10:33PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Seth Forshee [mailto:seth.forshee at canonical.com]
> > Sent: Tuesday, October 27, 2015 12:06 PM
> > To: Koenig, Christian
> > Cc: Deucher, Alexander; Oded Gabbay; dri-devel at lists.freedesktop.org
> > Subject: Re: Missing amdgpu firmware files
> > 
> > On Tue, Oct 27, 2015 at 04:47:53PM +0100, Christian König wrote:
> > > Well that's strange. Essentially those are just duplicates to the
> > > existing files and the driver should fallback to them.
> > >
> > > IIRC the radeon/*_sdma1.bin files are only requested when you try to
> > > use CIK support with amdgpu which isn't a good idea in a production
> > > environment.
> > >
> > > What's the link for the bug reports? It's most likely just people
> > > trying to use the driver with hardware which it isn't supposed to be
> > > used with.
> > 
> > There have been a few reports that the firmware is missing, but only one
> > I see where the user actually reports any display problems.
> > 
> >  http://bugs.launchpad.net/bugs/1510405
> > 
> > Of course it's possible that he is jumping to conclusions about the
> > missing firmware files causing his display issues.
> 
> The driver refuses to load if the firmware is missing.  However, as Christian 
> mentioned, you will only get those messages if you've enabled CIK support 
> amdgpu which we don't recommend (controlled by CONFIG_DRM_AMDGPU_CIK).  
> Radeon does not require the additional firmware.

Got it, thanks. I'll disable it.

Seth

No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c

2015-10-27 Thread Alex Deucher 
On Tue, Oct 27, 2015 at 6:06 AM, Michael Burian  
wrote:
> On 10/27/15 10:17, Michel Dänzer wrote:
>>
>> I'm not familiar with the ATOM bytecode, but since the number of
>> bytecode instructions executed seems the same in both cases, I suspect
>> that dig->backlight_level == 0 => ATOM_LCD_BLOFF is executed. (The
>> debugging output in my patch would have provided all of this information
>> and more, but there wasn't any of it in the dmesg you provided)
>>
>> I guess the question then becomes how dig->backlight_level is (supposed
>> to be) initialized.
>>
>> What values do the following files contain in the broken and working cases?
>>
>> /sys/class/backlight/radeon_bl0/bl_power
>> /sys/class/backlight/radeon_bl0/brightness
>> /sys/class/backlight/radeon_bl0/actual_brightness
>> /sys/class/backlight/radeon_bl0/max_brightness
>>
>>
>
> These files do not exist on my system,
> I can offer /sys/class/backlight/acpi_video0/
>
> content is identical in both cases
>
> bl_power0
> brightness  10
> actual_brightness   10
> max_brightness  10
>
>

It would appear that your system does not use the gpu backlight
controller.  Either it's lying or messing with the GPU backlight
controller causes some bad interaction with whatever does control it.
Does the attached radeon patch help?  I'm also attaching an amdgpu
patch for reference in case the same problem appears on amdgpu.

Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0002-drm-amdgpu-fix-backlight-handling-when-not-controlle.patch
Type: text/x-patch
Size: 2441 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/252b8352/attachment.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-backlight-handling-when-not-controlle.patch
Type: text/x-patch
Size: 2601 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/252b8352/attachment-0001.bin>

No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c

2015-10-27 Thread Michael Burian 
On 10/27/15 10:17, Michel Dänzer wrote:
> 
> I'm not familiar with the ATOM bytecode, but since the number of
> bytecode instructions executed seems the same in both cases, I suspect
> that dig->backlight_level == 0 => ATOM_LCD_BLOFF is executed. (The
> debugging output in my patch would have provided all of this information
> and more, but there wasn't any of it in the dmesg you provided)
> 
> I guess the question then becomes how dig->backlight_level is (supposed
> to be) initialized.
> 
> What values do the following files contain in the broken and working cases?
> 
> /sys/class/backlight/radeon_bl0/bl_power
> /sys/class/backlight/radeon_bl0/brightness
> /sys/class/backlight/radeon_bl0/actual_brightness
> /sys/class/backlight/radeon_bl0/max_brightness
> 
> 

These files do not exist on my system,
I can offer /sys/class/backlight/acpi_video0/

content is identical in both cases

bl_power0
brightness  10
actual_brightness   10
max_brightness  10

Missing amdgpu firmware files

2015-10-27 Thread Seth Forshee 
On Tue, Oct 27, 2015 at 04:47:53PM +0100, Christian König wrote:
> Well that's strange. Essentially those are just duplicates to the
> existing files and the driver should fallback to them.
> 
> IIRC the radeon/*_sdma1.bin files are only requested when you try to
> use CIK support with amdgpu which isn't a good idea in a production
> environment.
> 
> What's the link for the bug reports? It's most likely just people
> trying to use the driver with hardware which it isn't supposed to be
> used with.

There have been a few reports that the firmware is missing, but only one
I see where the user actually reports any display problems.

 http://bugs.launchpad.net/bugs/1510405

Of course it's possible that he is jumping to conclusions about the
missing firmware files causing his display issues.

Thanks,
Seth

[PATCH] drm/msm/mdp5: high precision vblank timestamp support

2015-10-27 Thread Archit Taneja 


On 10/27/2015 05:33 AM, Rob Clark wrote:
> On Mon, Oct 26, 2015 at 5:54 AM, Archit Taneja  
> wrote:
>> MDP5 has line count and frame count registers for each interface. Enable
>> these counters and use them to implement the get_vblank_timestamp drm
>> driver op.
>>
>> The line counter starts with the value 1 at the beginning of the VSYNC
>> pulse and ends with value VTOTAL at the end of VFP. This value is used
>> to determine whether we're in blanking period or not, and an adjusted
>> value of this counter is used to get vpos as expected by
>> get_scanout_position. Since there is no way to calculate hpos, we always
>> set it to 0.
>
> What are the odds that mdp(n!=5) could support the same?  If/when that
> ever happens I could see making some of this helpers to duplicate a
> bit less in mdpN backend.. but I guess also fine to cross that bridge
> when we come to it.  Other than that, lgtm, thanks

The MDP4 line counter only loops within the active region, making it 
sort of ineffective. That's the main reason why I didn't attempt to 
implement it for mdp4.

There seems to be a 12 bit frame counter available to implement a
vblank counter, but without the line counter, I'm not sure if that'll
be any better than using the software vblank counter.

Archit

>
> BR,
> -R
>
>> Signed-off-by: Archit Taneja 
>> ---
>>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c |  18 
>>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 129 
>> 
>>   drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   2 +
>>   3 files changed, 149 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c 
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
>> index c9e32b0..a019656 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
>> @@ -293,6 +293,24 @@ static const struct drm_encoder_helper_funcs 
>> mdp5_encoder_helper_funcs = {
>>  .enable = mdp5_encoder_enable,
>>   };
>>
>> +int mdp5_encoder_get_linecount(struct drm_encoder *encoder)
>> +{
>> +   struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
>> +   struct mdp5_kms *mdp5_kms = get_kms(encoder);
>> +   int intf = mdp5_encoder->intf.num;
>> +
>> +   return mdp5_read(mdp5_kms, REG_MDP5_INTF_LINE_COUNT(intf));
>> +}
>> +
>> +u32 mdp5_encoder_get_framecount(struct drm_encoder *encoder)
>> +{
>> +   struct mdp5_encoder *mdp5_encoder = to_mdp5_encoder(encoder);
>> +   struct mdp5_kms *mdp5_kms = get_kms(encoder);
>> +   int intf = mdp5_encoder->intf.num;
>> +
>> +   return mdp5_read(mdp5_kms, REG_MDP5_INTF_FRAME_COUNT(intf));
>> +}
>> +
>>   int mdp5_encoder_set_split_display(struct drm_encoder *encoder,
>>  struct drm_encoder *slave_encoder)
>>   {
>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> index b532faa..e115318 100644
>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>> @@ -468,6 +468,127 @@ static int get_clk(struct platform_device *pdev, 
>> struct clk **clkp,
>>  return 0;
>>   }
>>
>> +static struct drm_encoder *get_encoder_from_crtc(struct drm_crtc *crtc)
>> +{
>> +   struct drm_device *dev = crtc->dev;
>> +   struct drm_encoder *encoder;
>> +
>> +   drm_for_each_encoder(encoder, dev)
>> +   if (encoder->crtc == crtc)
>> +   return encoder;
>> +
>> +   return NULL;
>> +}
>> +
>> +static int mdp5_get_scanoutpos(struct drm_device *dev, unsigned int pipe,
>> +  unsigned int flags, int *vpos, int *hpos,
>> +  ktime_t *stime, ktime_t *etime,
>> +  const struct drm_display_mode *mode)
>> +{
>> +   struct msm_drm_private *priv = dev->dev_private;
>> +   struct drm_crtc *crtc;
>> +   struct drm_encoder *encoder;
>> +   int line, vsw, vbp, vactive_start, vactive_end, vfp_end;
>> +   int ret = 0;
>> +
>> +   crtc = priv->crtcs[pipe];
>> +   if (!crtc) {
>> +   DRM_ERROR("Invalid crtc %d\n", pipe);
>> +   return 0;
>> +   }
>> +
>> +   encoder = get_encoder_from_crtc(crtc);
>> +   if (!encoder) {
>> +   DRM_ERROR("no encoder found for crtc %d\n", pipe);
>> +   return 0;
>> +   }
>> +
>> +   ret |= DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE;
>> +
>> +   vsw = mode->crtc_vsync_end - mode->crtc_vsync_start;
>> +   vbp = mode->crtc_vtotal - mode->crtc_vsync_end;
>> +
>> +   /*
>> +* the line counter is 1 at the start of the VSYNC pulse and VTOTAL 
>> at
>> +* the end of VFP. Translate the porch values relative to the line
>> +* counter positions.
>> +*/
>> +
>> +   vactive_start = vsw + vbp + 1;
>> +
>> +   vactive_end = vactive_start + mode->crtc_vdisplay;
>> +
>> +   /* last scan line before VSYNC */
>> +

Missing amdgpu firmware files

2015-10-27 Thread Seth Forshee 
I've received reports from Ubuntu users about missing amdgpu firmware
files with 4.2 kernels. The driver calls out a number of
radeon/*_sdma1.bin files that are not present in the linux-firmware git
repo. Are these files available anywhere (under a license that allows
redistribution), and will they be pushed up to linux-firmware anytime
soon?

Thanks,
Seth

[Linux v4.3-rc6] i915: issues with Skylake integrated graphics

2015-10-27 Thread Jani Nikula 
On Tue, 27 Oct 2015, Eric Biggers  wrote:
> On Mon, Oct 26, 2015 at 03:28:37PM +0200, Jani Nikula wrote:
>> Please file two separate bugs at [1], one for the above, and another for
>> the below. Please add drm.debug=14 module parameter, and attach dmesg
>> all the way from boot to the problem.
>
> I have filed https://bugs.freedesktop.org/show_bug.cgi?id=92685 for the second
> part.  I did not, however, re-experience the first warning (the
> "WARN_ON(p->pixel_rate == 0)") after upgrading to Linux v4.3-rc7 and rebooting
> several times.

Thanks for the report.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

No backlight since linux-4.2.4 - drivers/gpu/drm/radeon/atombios_encoders.c

2015-10-27 Thread Michael Burian 
On 10/27/15 03:36, Michel Dänzer wrote:
>>
>> [0] contains dmesg output with your patch applied (which fixes the backlight 
>> issue)
> 
> This is very surprising: The patch just adds some debugging output, it's
> not supposed to have any functional effect. Also, I don't see any of the
> debugging output added by the patch in
> dmesg-4.3.0-rc7-3-g85051e2-dirty-2015-10-26-11-00-41-radeon-bl-debug.
>

> Are you sure that my patch was actually applied to the radeon driver
> when generating that file? Did you update the initrd with the patched
> radeon.ko?
> 

the build was done using "make -j4 deb-pkg" on a better equipped machine,
.deb packages were copied over and installed - maybe something interesting
happened

AFAICT the patch should have been applied, at least it was shown with
git diff and the -dirty suffix was added by the build system, not me.
All graphics related drivers are compiled in (=y) rather than as
modules (=m) in .config.

Another thing I tried yesterday was to add the old way right below the new one
(this fixes the backlight issue) enclosed by some debug statements that indicate
start / stop of the old / new method. (see atomdebug.diff - should be applied 
against
mainline)

-- next part --
radeon_start_backlight_new_way
>> execute D2AA (len 348, WS 4, PS 4)
   SET_ATI_PORT @ 0xD2B0
  port: 0 (MM)
   COMPARE_PS @ 0xD2B3
  src1: 
PS[0x00,0x8802]
.[7:0] -> 0x02
  src2: 
IMM 0x04
  result: NE LE
   JUMP_EQUAL @ 0xD2B7
  taken: no
  target: 0x0128
   COMPARE_PS @ 0xD2BA
  src1: 
PS[0x00,0x8802]
.[7:0] -> 0x02
  src2: 
IMM 0x05
  result: NE LE
   JUMP_EQUAL @ 0xD2BE
  taken: no
  target: 0x0113
   COMPARE_PS @ 0xD2C1
  src1: 
PS[0x00,0x8802]
.[7:0] -> 0x02
  src2: 
IMM 0x00
  result: NE GT
   JUMP_EQUAL @ 0xD2C5
  taken: no
  target: 0x00D8
   COMPARE_PS @ 0xD2C8
  src1: 
PS[0x00,0x8802]
.[7:0] -> 0x02
  src2: 
IMM 0x01
  result: NE GT
   JUMP_NOT_EQUAL @ 0xD2CC
  taken: yes
  target: 0x013D
   COMPARE_PS @ 0xD3E7
  src1: 
PS[0x00,0x8802]
.[7:0] -> 0x02
  src2: 
IMM 0x03
  result: NE LE
   JUMP_NOT_EQUAL @ 0xD3EB
  taken: yes
  target: 0x0151
   OR_REG @ 0xD3FB
  dst: 
REG[0x1EBC]
.[31:24] -> 0x00
  src: 
IMM 0x02
  dst: 
REG[0x1EBC]
.[31:24] <- 0x02
   AND_REG @ 0xD400
  dst: 
REG[0x1EBC]
.[31:24] -> 0x02
  src: 
IMM 0xFE
  dst: 
REG[0x1EBC]
.[31:24] <- 0x02
   EOT @ 0xD405
<<
radeon_stop_backlight_new_wayradeon_start_backlight_old_way
-- next part --
radeon_stop_backlight_new_wayradeon_start_backlight_old_way
>> execute D2AA (len 348, WS 4, PS 4)
   SET_ATI_PORT @ 0xD2B0
  port: 0 (MM)
   COMPARE_PS @ 0xD2B3
  src1: 
PS[0x00,0x0003]
.[7:0] -> 0x03
  src2: 
IMM 0x04
  result: NE LE
   JUMP_EQUAL @ 0xD2B7
  taken: no
  target: 0x0128
   COMPARE_PS @ 0xD2BA
  src1: 
PS[0x00,0x0003]
.[7:0] -> 0x03
  src2: 
IMM 0x05
  result: NE LE
   JUMP_EQUAL @ 0xD2BE
  taken: no
  target: 0x0113
   COMPARE_PS @ 0xD2C1
  src1: 
PS[0x00,0x0003]
.[7:0] -> 0x03
  src2: 
IMM 0x00
  result: NE GT
   JUMP_EQUAL @ 0xD2C5
  taken: no
  target: 0x00D8
   COMPARE_PS @ 0xD2C8
  src1: 
PS[0x00,0x0003]
.[7:0] -> 0x03
  src2: 
IMM 0x01
  result: NE GT
   JUMP_NOT_EQUAL @ 0xD2CC
  taken: yes
  target: 0x013D
   COMPARE_PS @ 0xD3E7
  src1: 
PS[0x00,0x0003]
.[7:0] -> 0x03
  src2: 
IMM 0x03
  result: EQ LE
   JUMP_NOT_EQUAL @ 0xD3EB
  taken: no
  target: 0x0151
   OR_REG @ 0xD3EE
  dst: 
REG[0x1EBC]
.[31:24] -> 0x02
  src: 
IMM 0x02
  dst: 
REG[0x1EBC]
.[31:24] <- 0x02
   OR_REG @ 0xD3F3
  dst: 
REG[0x1EBC]
.[31:24] -> 0x02
  src: 
IMM 0x01
  dst: 
REG[0x1EBC]
.[31:24] <- 0x03
   JUMP @ 0xD3F8
  target: 0x015B
   EOT @ 0xD405
<<
radeon_stop_backlight_old_way
-- next part --
A non-text attachment was scrubbed...
Name: atomdebug.diff
Type: text/x-patch
Size: 1430 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151027/a392214c/attachment-0001.bin>

[Bug 92309] Box drawn around cursor in multiple 3D games

2015-10-27 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92309

--- Comment #11 from Kamil Páral  ---
Thanks, Michel, that sounds plausible. In that case it seems we can close this
bug and the only thing to do here is to ask the developers to fix their games.

-- 
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/20151027/d9c69f3c/attachment.html>

[Bug 92309] Box drawn around cursor in multiple 3D games

2015-10-27 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=92309

--- Comment #10 from Michel Dänzer  ---
Presumably the cursor isn't captured by apitrace because it's not rendered
using OpenGL but uses the Xcursor* APIs. The artifacts are most likely due to
the cursor image not using proper pre-mulitplied alpha data as expected by
those APIs, which apparently happens to "work" to some degree with other
drivers / hardware.

-- 
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/20151027/aa282ace/attachment.html>

[GIT PULL] On-demand device probing

2015-10-27 Thread Rafael J. Wysocki 
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
> 
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> > 
> > > Furthermore, that applies only to devices that use synchronous suspend.  
> > > Async suspend is becoming common, and there the only restrictions are 
> > > parent-child relations plus whatever explicit requirements that drivers 
> > > impose by calling device_pm_wait_for_dev().
> > 
> > Hrm, this is the first I'd noticed that feature though I see the initial
> > commit dates from January.
> 
> Async suspend and device_pm_wait_for_dev() were added in January 2010, 
> not 2015!
> 
> >  It looks like most of the users are PCs at
> > the minute but we should be using it more widely for embedded things,
> > there's definitely some cases I'm aware of where it will allow us to
> > remove some open coding.
> > 
> > It does seem like we want to be feeding dependency information we
> > discover for probing way into the suspend dependencies...
> 
> Rafael has been thinking about a way to do this systematically.  
> Nothing concrete has emerged yet.

Well, good point. :-)

I've been kind of struggling with finding time to work on the patches lately
and some aspects of the design are still not finalized.  It seems, though, that
it can be beneficial to discuss the approach in general, so let me start a new
thread for that.

Thanks,
Rafael

[Bug 106291] amdgpu fails GPU reset when resuming from suspend

2015-10-27 Thread bugzilla-dae...@bugzilla.kernel.org 
https://bugzilla.kernel.org/show_bug.cgi?id=106291

--- Comment #7 from Michel Dänzer  ---
The log from 4.3-rc6 doesn't show any trace of the amdgpu driver. Did you
accidentally disable it when compiling that kernel?

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

[GIT PULL] On-demand device probing

2015-10-27 Thread Rafael J. Wysocki 
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
 wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown  wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I'm not quite sure why exactly everyone is so focused on probing 
>> >> here.
>> >
>> > Probe deferral is really noisy even if it's working fine on a given
>> > system so it's constantly being highlighted to people in a way that
>> > other issues aren't if you're not directly having problems.
>> >
>> > There's also the understanding people had that the order things get
>> > bound changes the ordering for some of the other cases (perhaps it's a
>> > good idea to do that, it seems likely to be sensible?).
>>
>> But it really doesn't do that.  Also making it do so doesn't help much
>> in the cases where things can happen asynchronously (system
>> suspend/resume, runtime PM).
>>
>> If, instead, there was a way to specify a functional dependency at the
>> device registration time, it might be used to change the order of
>> everything relevant, including probe.  That should help to reduce the
>> noise you're referring to.
>
> Taking it a step further, if functional dependencies were understood at
> link-time then we could optimize link order as well. There are probably
> lots of optimizations if we only made the effort to understand these
> dependencies earlier.

Do you mean the kernel link time or something else?

At least in some cases the dependency information won't be known at
that time, so we need a way to record a dependency at the time it
becomes visible to us anyway.

> Constructing the device/resource dependency graph before the device ever
> boots sounds interesting to me.

That's only practical if you build the kernel for a specific device.
If you want a generic binary that can work with multiple different
devices, that graph may very well be different for each of them.

Thanks,
Rafael