[PATCH 1/3] add common fan control asic callbacks
Adds 4 callbacks for managing fan state/speed
* fan_ctrl_set_mode - manages fan control mode (nonzero == manual)
* fan_ctrl_get_mode - queries fan control mode
* set_fan_speed_percent - manages fan speed as percentage value
* get_fan_speed_percent - queries fan speed as percentage value
Signed-off-by: Oleg Chernovskiy
---
drivers/gpu/drm/radeon/radeon.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 54529b8..4195e6c 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1967,6 +1967,10 @@ struct radeon_asic {
bool (*vblank_too_short)(struct radeon_device *rdev);
void (*powergate_uvd)(struct radeon_device *rdev, bool gate);
void (*enable_bapm)(struct radeon_device *rdev, bool enable);
+ void (*fan_ctrl_set_mode)(struct radeon_device *rdev, u32 mode);
+ u32 (*fan_ctrl_get_mode)(struct radeon_device *rdev);
+ int (*set_fan_speed_percent)(struct radeon_device *rdev, u32
speed);
+ int (*get_fan_speed_percent)(struct radeon_device *rdev, u32
*speed);
} dpm;
/* pageflipping */
struct {
--
2.1.3
[PATCH 2/3] add hwmon interface for managing fan pwm
This adds percent-based fan control. Attributes (I hope) follow the
sysfs-interface specification:
* pwm1 - fan speed query/manage
* pwm1_max, pwm1_min - min/max values for fan pwm (constant)
* pwm1_enable - fan control query/manage (enable/disable)
(There is no rpm-based control for now)
Signed-off-by: Oleg Chernovskiy
---
drivers/gpu/drm/radeon/radeon_pm.c | 129 -
1 file changed, 128 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 32522cc..58daa23 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -24,6 +24,7 @@
#include "radeon.h"
#include "avivod.h"
#include "atom.h"
+#include "r600_dpm.h"
#include
#include
#include
@@ -554,6 +555,94 @@ fail:
return count;
}
+static ssize_t radeon_hwmon_get_pwm1_enable(struct device *dev,
+ struct
device_attribute *attr,
+ char *buf)
+{
+ struct radeon_device *rdev = dev_get_drvdata(dev);
+ u32 pwm_mode = 0;
+
+ if(rdev->asic->dpm.fan_ctrl_get_mode)
+ pwm_mode = rdev->asic->dpm.fan_ctrl_get_mode(rdev);
+
+ return sprintf(buf, "%i\n", pwm_mode == FDO_PWM_MODE_STATIC);
+}
+
+static ssize_t radeon_hwmon_set_pwm1_enable(struct device *dev,
+ struct
device_attribute *attr,
+ const char *buf,
+ size_t count)
+{
+ struct radeon_device *rdev = dev_get_drvdata(dev);
+ int err;
+ int value;
+
+ if(!rdev->asic->dpm.fan_ctrl_set_mode)
+ return -EINVAL;
+
+ err = kstrtoint(buf, 10, &value);
+ if(err)
+ return err;
+
+ switch(value) {
+ case 1: // manual, percent-based
+ rdev->asic->dpm.fan_ctrl_set_mode(rdev, FDO_PWM_MODE_STATIC);
+ break;
+ default: // disable
+ rdev->asic->dpm.fan_ctrl_set_mode(rdev, 0);
+ break;
+ }
+
+ return count;
+}
+
+static ssize_t radeon_hwmon_get_pwm1_min(struct device *dev,
+ struct
device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%i\n", 0);
+}
+
+static ssize_t radeon_hwmon_get_pwm1_max(struct device *dev,
+ struct
device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%i\n", 100); // pwm uses percent-based fan-control
+}
+
+static ssize_t radeon_hwmon_set_pwm1(struct device *dev,
+ struct
device_attribute *attr,
+ const char *buf,
size_t count)
+{
+ struct radeon_device *rdev = dev_get_drvdata(dev);
+ int err;
+ u32 value;
+
+ err = kstrtou32(buf, 10, &value);
+ if(err)
+ return err;
+
+ err = rdev->asic->dpm.set_fan_speed_percent(rdev, value);
+ if(err)
+ return err;
+
+ return count;
+}
+
+static ssize_t radeon_hwmon_get_pwm1(struct device *dev,
+ struct
device_attribute *attr,
+ char *buf)
+{
+ struct radeon_device *rdev = dev_get_drvdata(dev);
+ int err;
+ u32 speed;
+ err = rdev->asic->dpm.get_fan_speed_percent(rdev, &speed);
+ if(err)
+ return err;
+
+ return sprintf(buf, "%i\n", speed);
+}
+
static DEVICE_ATTR(power_profile, S_IRUGO | S_IWUSR, radeon_get_pm_profile,
radeon_set_pm_profile);
static DEVICE_ATTR(power_method, S_IRUGO | S_IWUSR, radeon_get_pm_method,
radeon_set_pm_method);
static DEVICE_ATTR(power_dpm_state, S_IRUGO | S_IWUSR, radeon_get_dpm_state,
radeon_set_dpm_state);
@@ -601,11 +690,20 @@ static ssize_t radeon_hwmon_show_temp_thresh(struct
device *dev,
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, radeon_hwmon_show_temp, NULL,
0);
static SENSOR_DEVICE_ATTR(temp1_crit, S_IRUGO, radeon_hwmon_show_temp_thresh,
NULL, 0);
static SENSOR_DEVICE_ATTR(temp1_crit_hyst, S_IRUGO,
radeon_hwmon_show_temp_thresh, NULL, 1);
+static SENSOR_DEVICE_ATTR(pwm1, S_IRUGO | S_IWUSR, radeon_hwmon_get_pwm1,
radeon_hwmon_set_pwm1, 0);
+static SENSOR_DEVICE_ATTR(pwm1_enable, S_IRUGO | S_IWUSR,
radeon_hwmon_get_pwm1_enable, radeon_hwmon_set_pwm1_enable, 0);
+static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO, radeon_hwmon_get_pwm1_min, NULL,
0);
+static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO, radeon_hwmon_get_pwm1_max, NULL,
0);
+
static struct attribute *hwmon_attributes[] = {
&sensor_dev_a
[PATCH 3/3] bind fan control on CI cards to hwmon interface
This adds a possibility to control fan on CI parts
via exported hwmon variables. Note that automatic
ucode fan management pauses if you choose to enable
manual fan control
Signed-off-by: Oleg Chernovskiy
---
drivers/gpu/drm/radeon/ci_dpm.c | 32
drivers/gpu/drm/radeon/radeon_asic.c | 4
drivers/gpu/drm/radeon/radeon_asic.h | 7 +++
3 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index f373a81..cbba2b6 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -187,6 +187,8 @@ static int ci_update_uvd_dpm(struct radeon_device *rdev,
bool gate);
static PPSMC_Result ci_send_msg_to_smc_with_parameter(struct radeon_device
*rdev,
PPSMC_Msg msg, u32
parameter);
+static void ci_thermal_start_smc_fan_control(struct radeon_device *rdev);
+
static struct ci_power_info *ci_get_pi(struct radeon_device *rdev)
{
struct ci_power_info *pi = rdev->pm.dpm.priv;
@@ -1046,7 +1048,6 @@ static int ci_fan_ctrl_start_smc_fan_control(struct
radeon_device *rdev)
return 0;
}
-#if 0
static int ci_fan_ctrl_stop_smc_fan_control(struct radeon_device *rdev)
{
PPSMC_Result ret;
@@ -1058,7 +1059,7 @@ static int ci_fan_ctrl_stop_smc_fan_control(struct
radeon_device *rdev)
return -EINVAL;
}
-static int ci_fan_ctrl_get_fan_speed_percent(struct radeon_device *rdev,
+int ci_fan_ctrl_get_fan_speed_percent(struct radeon_device *rdev,
u32 *speed)
{
u32 duty, duty100;
@@ -1083,7 +1084,7 @@ static int ci_fan_ctrl_get_fan_speed_percent(struct
radeon_device *rdev,
return 0;
}
-static int ci_fan_ctrl_set_fan_speed_percent(struct radeon_device *rdev,
+int ci_fan_ctrl_set_fan_speed_percent(struct radeon_device *rdev,
u32 speed)
{
u32 tmp;
@@ -1096,9 +1097,6 @@ static int ci_fan_ctrl_set_fan_speed_percent(struct
radeon_device *rdev,
if (speed > 100)
return -EINVAL;
- if (rdev->pm.dpm.fan.ucode_fan_control)
- ci_fan_ctrl_stop_smc_fan_control(rdev);
-
duty100 = (RREG32_SMC(CG_FDO_CTRL1) & FMAX_DUTY100_MASK) >>
FMAX_DUTY100_SHIFT;
if (duty100 == 0)
@@ -1112,11 +1110,29 @@ static int ci_fan_ctrl_set_fan_speed_percent(struct
radeon_device *rdev,
tmp |= FDO_STATIC_DUTY(duty);
WREG32_SMC(CG_FDO_CTRL0, tmp);
- ci_fan_ctrl_set_static_mode(rdev, FDO_PWM_MODE_STATIC);
-
return 0;
}
+void ci_fan_ctrl_set_mode(struct radeon_device *rdev, u32 mode)
+{
+ if(mode) {
+ // stop auto-manage
+ if (rdev->pm.dpm.fan.ucode_fan_control)
+ ci_fan_ctrl_stop_smc_fan_control(rdev);
+ ci_fan_ctrl_set_static_mode(rdev, mode);
+ } else {
+ // restart auto-manage
+ ci_thermal_start_smc_fan_control(rdev);
+ }
+}
+
+u32 ci_fan_cntrl_get_mode(struct radeon_device *rdev)
+{
+ u32 tmp = RREG32_SMC(CG_FDO_CTRL2) & FDO_PWM_MODE_MASK;
+ return (tmp >> FDO_PWM_MODE_SHIFT);
+}
+
+#if 0
static int ci_fan_ctrl_get_fan_speed_rpm(struct radeon_device *rdev,
u32 *speed)
{
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 850de57..d2c517c 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -2104,6 +2104,10 @@ static struct radeon_asic ci_asic = {
.force_performance_level = &ci_dpm_force_performance_level,
.vblank_too_short = &ci_dpm_vblank_too_short,
.powergate_uvd = &ci_dpm_powergate_uvd,
+ .fan_ctrl_set_mode = &ci_fan_ctrl_set_mode,
+ .fan_ctrl_get_mode = &ci_fan_cntrl_get_mode,
+ .get_fan_speed_percent = &ci_fan_ctrl_get_fan_speed_percent,
+ .set_fan_speed_percent = &ci_fan_ctrl_set_fan_speed_percent,
},
.pflip = {
.page_flip = &evergreen_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 2a45d54..edd64dc 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -861,6 +861,13 @@ int ci_dpm_force_performance_level(struct radeon_device
*rdev,
bool ci_dpm_vblank_too_short(struct radeon_device *rdev);
void ci_dpm_powergate_uvd(struct radeon_device *rdev, bool gate);
+int ci_fan_ctrl_get_fan_speed_percent(struct radeon_device *rdev,
+u32 *speed);
+int ci_fan_ctrl_set_fan_speed_percent(struct radeon_device *rdev,
+u32 speed);
+u32 ci_fan_cntrl_get_mode(struct radeon_device *rdev);
+void ci_fan_ctrl_set_mode(struct radeon_device *rdev, u32 mode);
+
int
[PATCH 0/20] fix misspelling of current function in string
Hi Julia, On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall wrote: > These patches replace what appears to be a reference to the name of the > current function but is misspelled in some way by either the name of the > function itself, or by %s and then __func__ in an argument list. Would there be any value in doing this for _all_ cases where the function name is written in a format string? Thanks, -- Julian Calaby Email: julian.calaby at gmail.com Profile: http://www.google.com/profiles/julian.calaby/
[Bug 82886] [RadeonSI]GPU Lockup with Linux 3.16 & Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=82886 --- Comment #3 from Jarkko K --- I think you should try to update kernel and mesa. Both are updated regularly. -- 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/20141208/fe0e2f63/attachment.html>
WARNING: /usr/projects/linux/linux/drivers/gpu/drm/i915/intel_pm.c:6585 intel_display_power_put+0x4b/0x116 [i915]()
On 8 December 2014 at 10:34, Theodore Ts'o wrote: > This is an update to a problem which I reported several months ago > (see below). The symptoms have changed a bit since then, but they've > stablized since 3.17 and 3.18-rcX, and while annoying, it's tolerable, > so I've been living with it. > > What I'm basically seeing now is that any external monitor (either a > Dell 30" or Dell 24") will be seen after a reboot or a restart of the > X server. But if suspend the laptop, disconnect from the dock, and > resume, and then later on, reconnect to the dock, the external > monitors are not visible until I kill and restart the X server. > Another part of the symptom is when I try to probe for the monitors, > using either xrandr or xfce4-display-settings, the system freezes for > a second or two, and then when it recovers, if I look in the logs, I > see the following warning message, repeated twice: I suspect a lot of the problems are just that xfce isn't sufficiently handling randr events, and it is getting out of sync, it is like hotplug networking before NetworkManager etc. I just tried using XFCE from F21 and if I leave the display settings app open it crashes hard when I tried the cycle above, which didn't lend me much confidence, it also never reenabled the monitor when it came back, I've tried a few cycles of this with GNOME desktop and it seems to work pretty well. I'll try reproducing the exact problem you are seeing however, I haven't managed that with drm-next tree which has v3.18 merged now. The i915 driver also has a tendency to WARN_ON on pointless things, the i915 developers insist these are actual bugs, but don't insist on producing patches to fix them in a reasonable time frame or if they do, they add 5 more WARN_ONs to compensate. Dave.
[PATCH] drm/fb_helper: move deferred fb checking into restore mode (v2)
From: Dave Airlie
On MST systems the monitors don't appear when we set the fb up,
but plymouth opens the drm device and holds it open while they
come up, when plymouth finishes and lastclose gets called we
don't do the delayed fb probe, so the monitor never appears on the
console.
Fix this by moving the delayed checking into the mode restore.
v2: Daniel suggested that ->delayed_hotplug is set under
the mode_config mutex, so we should check it under that as
well, while we are in the area.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_fb_helper.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 37955b0..52ce26d 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -347,9 +347,18 @@ bool drm_fb_helper_restore_fbdev_mode_unlocked(struct
drm_fb_helper *fb_helper)
{
struct drm_device *dev = fb_helper->dev;
bool ret;
+ bool do_delayed = false;
+
drm_modeset_lock_all(dev);
ret = restore_fbdev_mode(fb_helper);
+
+ do_delayed = fb_helper->delayed_hotplug;
+ if (do_delayed)
+ fb_helper->delayed_hotplug = false;
drm_modeset_unlock_all(dev);
+
+ if (do_delayed)
+ drm_fb_helper_hotplug_event(fb_helper);
return ret;
}
EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
@@ -888,10 +897,6 @@ int drm_fb_helper_set_par(struct fb_info *info)
drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
- if (fb_helper->delayed_hotplug) {
- fb_helper->delayed_hotplug = false;
- drm_fb_helper_hotplug_event(fb_helper);
- }
return 0;
}
EXPORT_SYMBOL(drm_fb_helper_set_par);
--
2.1.0
[Bug 86832] [dota2][si] freezes up to 3 seconds when many/big display effects happen
https://bugs.freedesktop.org/show_bug.cgi?id=86832 Sylvain BERTRAND changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Sylvain BERTRAND --- not temporary freeze with this kernel seen. -- 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/20141208/498536ee/attachment.html>
[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg&fb buffers
https://bugs.freedesktop.org/show_bug.cgi?id=83998 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|DRM/Radeon Version|git |unspecified Product|Mesa|DRI --- Comment #10 from Michel Dänzer --- If there's an older kernel where this doesn't happen, it might be possible to bisect. -- 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/20141208/fdd034e7/attachment.html>
[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume
https://bugs.freedesktop.org/show_bug.cgi?id=86267 Michel Dänzer changed: What|Removed |Added Attachment #110348|0 |1 is obsolete|| --- Comment #11 from Michel Dänzer --- Created attachment 110555 --> https://bugs.freedesktop.org/attachment.cgi?id=110555&action=edit Add mb() andradeon_gart_tlb_flush() calls to radeon_gart_table_vram_pin How about this patch? -- 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/20141208/06327231/attachment.html>
[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM
On 11/12/2014 09:39 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> dma_alloc_coherent() returns a kernel virtual address that is part of
> the linear range. Passing such an address to virt_to_page() is illegal
> on non-coherent architectures. This causes the kernel to oops on 64-bit
> ARM because the struct page * obtained from virt_to_page() points to
> unmapped memory.
>
> This commit fixes this by using phys_to_page() since we get a physical
> address from dma_alloc_coherent(). Note that this is not a proper fix
> because if an IOMMU is set up to translate addresses for the GPU this
> address will be an I/O virtual address rather than a physical one. The
> proper fix probably involves not getting a pointer to the struct page
> in the first place, but that would be a much more intrusive change, if
> at all possible.
>
> Until that time, this temporary fix will allow TTM to work on 32-bit
> and 64-bit ARM as well, provided that no IOMMU translations are enabled
> for the GPU.
>
> Signed-off-by: Thierry Reding
> ---
> Arnd, I realize that this isn't a proper fix according to what we discussed on
> IRC yesterday, but I can't see a way to remove access to the pages array that
> would be as simple as this. I've marked this as RFC in the hope that it will
> trigger some discussion that will lead to a proper solution.
>
> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> index c96db433f8af..d7993985752c 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
> @@ -343,7 +343,11 @@ static struct dma_page *__ttm_dma_alloc_page(struct
> dma_pool *pool)
> &d_page->dma,
> pool->gfp_flags);
> if (d_page->vaddr)
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> + d_page->p = phys_to_page(d_page->dma);
> +#else
> d_page->p = virt_to_page(d_page->vaddr);
> +#endif
Since I am messing with the IOMMU I just happened to have hit the issue
you are mentioning. Wouldn't the following work:
- if (d_page->vaddr)
-#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
- d_page->p = phys_to_page(d_page->dma);
-#else
- d_page->p = virt_to_page(d_page->vaddr);
-#endif
- else {
+ if (d_page->vaddr) {
+ if (is_vmalloc_addr(d_page->vaddr)) {
+ d_page->p = vmalloc_to_page(d_page->vaddr);
+ } else {
+ d_page->p = virt_to_page(d_page->vaddr);
+ }
+ } else {
A remapped page will end up in the vmalloc range of the address space,
and in this case we can use vmalloc_to_page() to get the right page.
Pages outside of this range are part of the linear mapping and can be
resolved using virt_to_page().
Jetson seems to be mostly happy with this, although I sometimes get the
following trace:
[ 13.174763] kernel BUG at ../mm/slab.c:2593!
[ 13.174767] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 13.174790] Modules linked in: nouveau_platform(O+) nouveau(O)
cfbfillrect cfbimgblt cfbcopyarea ttm
...
[ 13.175234] [] (cache_alloc_refill) from []
(__kmalloc+0x100/0x13c)
[ 13.175247] [] (__kmalloc) from []
(arm_iommu_alloc_attrs+0x94/0x3a8)
[ 13.175269] [] (arm_iommu_alloc_attrs) from []
(ttm_dma_populate+0x498/0x76c [ttm])
[ 13.175294] [] (ttm_dma_populate [ttm]) from []
(ttm_tt_bind+0x38/0x68 [ttm])
[ 13.175315] [] (ttm_tt_bind [ttm]) from []
(ttm_bo_handle_move_mem+0x408/0x47c [ttm])
[ 13.175337] [] (ttm_bo_handle_move_mem [ttm]) from
[] (ttm_bo_validate+0x220/0x22c [ttm])
[ 13.175359] [] (ttm_bo_validate [ttm]) from []
(ttm_bo_init+0x220/0x338 [ttm])
[ 13.175480] [] (ttm_bo_init [ttm]) from []
(nouveau_bo_new+0x1c0/0x294 [nouveau])
[ 13.175688] [] (nouveau_bo_new [nouveau]) from []
(nv84_fence_create+0x1cc/0x240 [nouveau])
[ 13.175891] [] (nv84_fence_create [nouveau]) from
[] (nvc0_fence_create+0xc/0x24 [nouveau])
[ 13.176094] [] (nvc0_fence_create [nouveau]) from
[] (nouveau_accel_init+0xec/0x450 [nouveau])
I suspect this is related to this change, but it might also be the
side-effect of another bug in my code.
[Bug 85647] Random radeonsi crashes with mesa 10.3.x
https://bugs.freedesktop.org/show_bug.cgi?id=85647 --- Comment #38 from Hannu --- Created attachment 110558 --> https://bugs.freedesktop.org/attachment.cgi?id=110558&action=edit mesa 10.3.2-1 and linux 3.18.0 crash attached crash report from journalctl. Linux 3.18.0 and original debian mesa 10.3.2-1. I don't know if this adds anything new to report in attachment 108940, there are some differences though. -- 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/20141208/2109ff42/attachment-0001.html>
[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM
On 12/08/2014 04:14 PM, Alexandre Courbot wrote:
> On 11/12/2014 09:39 PM, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> dma_alloc_coherent() returns a kernel virtual address that is part of
>> the linear range. Passing such an address to virt_to_page() is illegal
>> on non-coherent architectures. This causes the kernel to oops on 64-bit
>> ARM because the struct page * obtained from virt_to_page() points to
>> unmapped memory.
>>
>> This commit fixes this by using phys_to_page() since we get a physical
>> address from dma_alloc_coherent(). Note that this is not a proper fix
>> because if an IOMMU is set up to translate addresses for the GPU this
>> address will be an I/O virtual address rather than a physical one. The
>> proper fix probably involves not getting a pointer to the struct page
>> in the first place, but that would be a much more intrusive change, if
>> at all possible.
>>
>> Until that time, this temporary fix will allow TTM to work on 32-bit
>> and 64-bit ARM as well, provided that no IOMMU translations are enabled
>> for the GPU.
>>
>> Signed-off-by: Thierry Reding
>> ---
>> Arnd, I realize that this isn't a proper fix according to what we
>> discussed on
>> IRC yesterday, but I can't see a way to remove access to the pages
>> array that
>> would be as simple as this. I've marked this as RFC in the hope that
>> it will
>> trigger some discussion that will lead to a proper solution.
>>
>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> index c96db433f8af..d7993985752c 100644
>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> @@ -343,7 +343,11 @@ static struct dma_page
>> *__ttm_dma_alloc_page(struct dma_pool *pool)
>> &d_page->dma,
>> pool->gfp_flags);
>> if (d_page->vaddr)
>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
>> +d_page->p = phys_to_page(d_page->dma);
>> +#else
>> d_page->p = virt_to_page(d_page->vaddr);
>> +#endif
>
> Since I am messing with the IOMMU I just happened to have hit the issue
> you are mentioning. Wouldn't the following work:
>
> - if (d_page->vaddr)
> -#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> - d_page->p = phys_to_page(d_page->dma);
> -#else
> - d_page->p = virt_to_page(d_page->vaddr);
> -#endif
> - else {
> + if (d_page->vaddr) {
> + if (is_vmalloc_addr(d_page->vaddr)) {
> + d_page->p = vmalloc_to_page(d_page->vaddr);
> + } else {
> + d_page->p = virt_to_page(d_page->vaddr);
> + }
> + } else {
>
> A remapped page will end up in the vmalloc range of the address space,
> and in this case we can use vmalloc_to_page() to get the right page.
> Pages outside of this range are part of the linear mapping and can be
> resolved using virt_to_page().
>
> Jetson seems to be mostly happy with this, although I sometimes get the
> following trace:
>
> [ 13.174763] kernel BUG at ../mm/slab.c:2593!
> [ 13.174767] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [ 13.174790] Modules linked in: nouveau_platform(O+) nouveau(O)
> cfbfillrect cfbimgblt cfbcopyarea ttm
> ...
> [ 13.175234] [] (cache_alloc_refill) from []
> (__kmalloc+0x100/0x13c)
> [ 13.175247] [] (__kmalloc) from []
> (arm_iommu_alloc_attrs+0x94/0x3a8)
> [ 13.175269] [] (arm_iommu_alloc_attrs) from []
> (ttm_dma_populate+0x498/0x76c [ttm])
> [ 13.175294] [] (ttm_dma_populate [ttm]) from []
> (ttm_tt_bind+0x38/0x68 [ttm])
> [ 13.175315] [] (ttm_tt_bind [ttm]) from []
> (ttm_bo_handle_move_mem+0x408/0x47c [ttm])
> [ 13.175337] [] (ttm_bo_handle_move_mem [ttm]) from
> [] (ttm_bo_validate+0x220/0x22c [ttm])
> [ 13.175359] [] (ttm_bo_validate [ttm]) from []
> (ttm_bo_init+0x220/0x338 [ttm])
> [ 13.175480] [] (ttm_bo_init [ttm]) from []
> (nouveau_bo_new+0x1c0/0x294 [nouveau])
> [ 13.175688] [] (nouveau_bo_new [nouveau]) from []
> (nv84_fence_create+0x1cc/0x240 [nouveau])
> [ 13.175891] [] (nv84_fence_create [nouveau]) from
> [] (nvc0_fence_create+0xc/0x24 [nouveau])
> [ 13.176094] [] (nvc0_fence_create [nouveau]) from
> [] (nouveau_accel_init+0xec/0x450 [nouveau])
>
> I suspect this is related to this change, but it might also be the
> side-effect of another bug in my code.
FWIW and after some more testing, I noticed that without IOMMU
vmalloc_to_page() and phys_to_page() both return the same valid page.
With the IOMMU enabled vmalloc_to_page() still returns what seems to be
valid pages (phys_to_page() of course doesn't make sense anymore).
So AFAICT the change I proposed seems valid. I am not sure what causes
the BUG() in the slab allocator.
[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM
On 12/08/2014 04:14 PM, Alexandre Courbot wrote:
> On 11/12/2014 09:39 PM, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> dma_alloc_coherent() returns a kernel virtual address that is part of
>> the linear range. Passing such an address to virt_to_page() is illegal
>> on non-coherent architectures. This causes the kernel to oops on 64-bit
>> ARM because the struct page * obtained from virt_to_page() points to
>> unmapped memory.
>>
>> This commit fixes this by using phys_to_page() since we get a physical
>> address from dma_alloc_coherent(). Note that this is not a proper fix
>> because if an IOMMU is set up to translate addresses for the GPU this
>> address will be an I/O virtual address rather than a physical one. The
>> proper fix probably involves not getting a pointer to the struct page
>> in the first place, but that would be a much more intrusive change, if
>> at all possible.
>>
>> Until that time, this temporary fix will allow TTM to work on 32-bit
>> and 64-bit ARM as well, provided that no IOMMU translations are enabled
>> for the GPU.
>>
>> Signed-off-by: Thierry Reding
>> ---
>> Arnd, I realize that this isn't a proper fix according to what we
>> discussed on
>> IRC yesterday, but I can't see a way to remove access to the pages
>> array that
>> would be as simple as this. I've marked this as RFC in the hope that
>> it will
>> trigger some discussion that will lead to a proper solution.
>>
>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> index c96db433f8af..d7993985752c 100644
>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>> @@ -343,7 +343,11 @@ static struct dma_page
>> *__ttm_dma_alloc_page(struct dma_pool *pool)
>> &d_page->dma,
>> pool->gfp_flags);
>> if (d_page->vaddr)
>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
>> +d_page->p = phys_to_page(d_page->dma);
>> +#else
>> d_page->p = virt_to_page(d_page->vaddr);
>> +#endif
>
> Since I am messing with the IOMMU I just happened to have hit the issue
> you are mentioning. Wouldn't the following work:
>
> - if (d_page->vaddr)
> -#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
> - d_page->p = phys_to_page(d_page->dma);
> -#else
> - d_page->p = virt_to_page(d_page->vaddr);
> -#endif
> - else {
> + if (d_page->vaddr) {
> + if (is_vmalloc_addr(d_page->vaddr)) {
> + d_page->p = vmalloc_to_page(d_page->vaddr);
> + } else {
> + d_page->p = virt_to_page(d_page->vaddr);
> + }
> + } else {
>
> A remapped page will end up in the vmalloc range of the address space,
> and in this case we can use vmalloc_to_page() to get the right page.
> Pages outside of this range are part of the linear mapping and can be
> resolved using virt_to_page().
>
> Jetson seems to be mostly happy with this, although I sometimes get the
> following trace:
>
> [ 13.174763] kernel BUG at ../mm/slab.c:2593!
> [ 13.174767] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> [ 13.174790] Modules linked in: nouveau_platform(O+) nouveau(O)
> cfbfillrect cfbimgblt cfbcopyarea ttm
> ...
> [ 13.175234] [] (cache_alloc_refill) from []
> (__kmalloc+0x100/0x13c)
> [ 13.175247] [] (__kmalloc) from []
> (arm_iommu_alloc_attrs+0x94/0x3a8)
> [ 13.175269] [] (arm_iommu_alloc_attrs) from []
> (ttm_dma_populate+0x498/0x76c [ttm])
> [ 13.175294] [] (ttm_dma_populate [ttm]) from []
> (ttm_tt_bind+0x38/0x68 [ttm])
> [ 13.175315] [] (ttm_tt_bind [ttm]) from []
> (ttm_bo_handle_move_mem+0x408/0x47c [ttm])
> [ 13.175337] [] (ttm_bo_handle_move_mem [ttm]) from
> [] (ttm_bo_validate+0x220/0x22c [ttm])
> [ 13.175359] [] (ttm_bo_validate [ttm]) from []
> (ttm_bo_init+0x220/0x338 [ttm])
> [ 13.175480] [] (ttm_bo_init [ttm]) from []
> (nouveau_bo_new+0x1c0/0x294 [nouveau])
> [ 13.175688] [] (nouveau_bo_new [nouveau]) from []
> (nv84_fence_create+0x1cc/0x240 [nouveau])
> [ 13.175891] [] (nv84_fence_create [nouveau]) from
> [] (nvc0_fence_create+0xc/0x24 [nouveau])
> [ 13.176094] [] (nvc0_fence_create [nouveau]) from
> [] (nouveau_accel_init+0xec/0x450 [nouveau])
>
> I suspect this is related to this change, but it might also be the
> side-effect of another bug in my code.
Ok, I finally understand where this trace comes from.
slab.c:2593:
BUG_ON(flags & GFP_SLAB_BUG_MASK);
gfp.h:
#define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
and ttm_dma_populate() calls ttm_dma_pool_init() with gfp_flags ==
GFP_HIGHUSER, which includes __GFP_HIGHMEM. Somehow these flags are
propagated through arm_iommu_alloc_attrs() up to the slab allocator,
which meets this BUG_ON() when it needs to grow its cache.
Note that ttm_dma_pool_init() can also be called
[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM
On 12/08/2014 05:11 PM, Alexandre Courbot wrote:
> On 12/08/2014 04:14 PM, Alexandre Courbot wrote:
>> On 11/12/2014 09:39 PM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> dma_alloc_coherent() returns a kernel virtual address that is part of
>>> the linear range. Passing such an address to virt_to_page() is illegal
>>> on non-coherent architectures. This causes the kernel to oops on 64-bit
>>> ARM because the struct page * obtained from virt_to_page() points to
>>> unmapped memory.
>>>
>>> This commit fixes this by using phys_to_page() since we get a physical
>>> address from dma_alloc_coherent(). Note that this is not a proper fix
>>> because if an IOMMU is set up to translate addresses for the GPU this
>>> address will be an I/O virtual address rather than a physical one. The
>>> proper fix probably involves not getting a pointer to the struct page
>>> in the first place, but that would be a much more intrusive change, if
>>> at all possible.
>>>
>>> Until that time, this temporary fix will allow TTM to work on 32-bit
>>> and 64-bit ARM as well, provided that no IOMMU translations are enabled
>>> for the GPU.
>>>
>>> Signed-off-by: Thierry Reding
>>> ---
>>> Arnd, I realize that this isn't a proper fix according to what we
>>> discussed on
>>> IRC yesterday, but I can't see a way to remove access to the pages
>>> array that
>>> would be as simple as this. I've marked this as RFC in the hope that
>>> it will
>>> trigger some discussion that will lead to a proper solution.
>>>
>>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> index c96db433f8af..d7993985752c 100644
>>> --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
>>> @@ -343,7 +343,11 @@ static struct dma_page
>>> *__ttm_dma_alloc_page(struct dma_pool *pool)
>>> &d_page->dma,
>>> pool->gfp_flags);
>>> if (d_page->vaddr)
>>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
>>> +d_page->p = phys_to_page(d_page->dma);
>>> +#else
>>> d_page->p = virt_to_page(d_page->vaddr);
>>> +#endif
>>
>> Since I am messing with the IOMMU I just happened to have hit the issue
>> you are mentioning. Wouldn't the following work:
>>
>> - if (d_page->vaddr)
>> -#if defined(CONFIG_ARM) || defined(CONFIG_ARM64)
>> - d_page->p = phys_to_page(d_page->dma);
>> -#else
>> - d_page->p = virt_to_page(d_page->vaddr);
>> -#endif
>> - else {
>> + if (d_page->vaddr) {
>> + if (is_vmalloc_addr(d_page->vaddr)) {
>> + d_page->p = vmalloc_to_page(d_page->vaddr);
>> + } else {
>> + d_page->p = virt_to_page(d_page->vaddr);
>> + }
>> + } else {
>>
>> A remapped page will end up in the vmalloc range of the address space,
>> and in this case we can use vmalloc_to_page() to get the right page.
>> Pages outside of this range are part of the linear mapping and can be
>> resolved using virt_to_page().
>>
>> Jetson seems to be mostly happy with this, although I sometimes get the
>> following trace:
>>
>> [ 13.174763] kernel BUG at ../mm/slab.c:2593!
>> [ 13.174767] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
>> [ 13.174790] Modules linked in: nouveau_platform(O+) nouveau(O)
>> cfbfillrect cfbimgblt cfbcopyarea ttm
>> ...
>> [ 13.175234] [] (cache_alloc_refill) from []
>> (__kmalloc+0x100/0x13c)
>> [ 13.175247] [] (__kmalloc) from []
>> (arm_iommu_alloc_attrs+0x94/0x3a8)
>> [ 13.175269] [] (arm_iommu_alloc_attrs) from []
>> (ttm_dma_populate+0x498/0x76c [ttm])
>> [ 13.175294] [] (ttm_dma_populate [ttm]) from []
>> (ttm_tt_bind+0x38/0x68 [ttm])
>> [ 13.175315] [] (ttm_tt_bind [ttm]) from []
>> (ttm_bo_handle_move_mem+0x408/0x47c [ttm])
>> [ 13.175337] [] (ttm_bo_handle_move_mem [ttm]) from
>> [] (ttm_bo_validate+0x220/0x22c [ttm])
>> [ 13.175359] [] (ttm_bo_validate [ttm]) from []
>> (ttm_bo_init+0x220/0x338 [ttm])
>> [ 13.175480] [] (ttm_bo_init [ttm]) from []
>> (nouveau_bo_new+0x1c0/0x294 [nouveau])
>> [ 13.175688] [] (nouveau_bo_new [nouveau]) from []
>> (nv84_fence_create+0x1cc/0x240 [nouveau])
>> [ 13.175891] [] (nv84_fence_create [nouveau]) from
>> [] (nvc0_fence_create+0xc/0x24 [nouveau])
>> [ 13.176094] [] (nvc0_fence_create [nouveau]) from
>> [] (nouveau_accel_init+0xec/0x450 [nouveau])
>>
>> I suspect this is related to this change, but it might also be the
>> side-effect of another bug in my code.
>
> Ok, I finally understand where this trace comes from.
>
> slab.c:2593:
> BUG_ON(flags & GFP_SLAB_BUG_MASK);
>
> gfp.h:
> #define GFP_SLAB_BUG_MASK (__GFP_DMA32|__GFP_HIGHMEM|~__GFP_BITS_MASK)
>
> and ttm_dma_populate() calls ttm_dma_pool_init() with gfp_flags ==
> GFP_HIGHUSER, which includes __GFP_HIGHMEM. Somehow these flags are
> pro
[PATCH] gpu: drm: i915: intel_display.c: Remove unused function
On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote: > Remove the function intel_output_name() that is not used anywhere. > > This was partially found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist Queued for 3.20, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/fb_helper: move deferred fb checking into restore mode (v2)
On Mon, Dec 08, 2014 at 01:38:59PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> On MST systems the monitors don't appear when we set the fb up,
> but plymouth opens the drm device and holds it open while they
> come up, when plymouth finishes and lastclose gets called we
> don't do the delayed fb probe, so the monitor never appears on the
> console.
>
> Fix this by moving the delayed checking into the mode restore.
>
> v2: Daniel suggested that ->delayed_hotplug is set under
> the mode_config mutex, so we should check it under that as
> well, while we are in the area.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 37955b0..52ce26d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -347,9 +347,18 @@ bool drm_fb_helper_restore_fbdev_mode_unlocked(struct
> drm_fb_helper *fb_helper)
> {
> struct drm_device *dev = fb_helper->dev;
> bool ret;
> + bool do_delayed = false;
> +
> drm_modeset_lock_all(dev);
> ret = restore_fbdev_mode(fb_helper);
> +
> + do_delayed = fb_helper->delayed_hotplug;
> + if (do_delayed)
> + fb_helper->delayed_hotplug = false;
> drm_modeset_unlock_all(dev);
> +
> + if (do_delayed)
> + drm_fb_helper_hotplug_event(fb_helper);
> return ret;
> }
> EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked);
> @@ -888,10 +897,6 @@ int drm_fb_helper_set_par(struct fb_info *info)
>
> drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
>
> - if (fb_helper->delayed_hotplug) {
> - fb_helper->delayed_hotplug = false;
> - drm_fb_helper_hotplug_event(fb_helper);
> - }
> return 0;
> }
> EXPORT_SYMBOL(drm_fb_helper_set_par);
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[GIT PULL] fixes for STI drm driver
Hello David,
This series of patches fix various issues in STI drm driver.
Now HDMI i2c adapter could be selected in device tree
and plug detection doesn't use gpio anymore.
I also had fix some signal timing problems after testing the driver
on more hardware.
The remaining patches attemps to simplify the code and prepare
the next evolutions like DVO and auxiliary CRTC support
The changes could be fetch here:
http://git.linaro.org/people/benjamin.gaignard/kernel.git
on drm-sti-fixes-2014-12-04 branch
I have tested this branch on top of commit:
"Merge branch 'drm-fixes-3.18' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes" 00d6a9b6be5885ad38234cd171f6fb18a87faa7c
on drm-fixes branch.
Benjamin Gaignard (9):
drm: sti: allow to change hdmi ddc i2c adapter
drm: sti: remove gpio for HDMI hot plug detection
drm: sti: clear all mixer control
drm: sti: simplify gdp code
drm: sti: remove event lock while disabling vblank
drm: sti: fix hdmi avi infoframe
drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off}
drm: sti: prepare sti_tvout to support auxiliary crtc
drm: sti: fix delay in VTG programming
.../devicetree/bindings/gpu/st,stih4xx.txt | 3 +-
drivers/gpu/drm/sti/sti_drm_crtc.c | 10 +--
drivers/gpu/drm/sti/sti_gdp.c | 39 -
drivers/gpu/drm/sti/sti_hdmi.c | 84 +++-
drivers/gpu/drm/sti/sti_hdmi.h | 6 +-
drivers/gpu/drm/sti/sti_mixer.c| 9 +++
drivers/gpu/drm/sti/sti_mixer.h| 1 +
drivers/gpu/drm/sti/sti_tvout.c| 92 --
drivers/gpu/drm/sti/sti_vtg.c | 31 +++-
9 files changed, 166 insertions(+), 109 deletions(-)
--
1.9.1
[PATCH] gpu: drm: i915: intel_sideband.c: Remove some unused functions
On Sun, 07 Dec 2014, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> vlv_flisdsi_read() vlv_gps_core_write() vlv_gps_core_read()
> vlv_ccu_write() vlv_ccu_read() vlv_gpio_nc_read()
I'd let them be.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/i915/i915_drv.h |6 -
> drivers/gpu/drm/i915/intel_sideband.c | 44
> -
> 2 files changed, 50 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 16a6f6d..d248957 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2849,23 +2849,17 @@ int sandybridge_pcode_write(struct drm_i915_private
> *dev_priv, u8 mbox, u32 val)
> u32 vlv_punit_read(struct drm_i915_private *dev_priv, u8 addr);
> void vlv_punit_write(struct drm_i915_private *dev_priv, u8 addr, u32 val);
> u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8 addr);
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> u32 vlv_cck_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_cck_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> u32 vlv_bunit_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_bunit_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg);
> -void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int
> reg);
> void vlv_dpio_write(struct drm_i915_private *dev_priv, enum pipe pipe, int
> reg, u32 val);
> u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg,
> enum intel_sbi_destination destination);
> void intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value,
>enum intel_sbi_destination destination);
> -u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
>
> int vlv_gpu_freq(struct drm_i915_private *dev_priv, int val);
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 01d841e..5939171 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -129,14 +129,6 @@ u32 vlv_nc_read(struct drm_i915_private *dev_priv, u8
> addr)
> return val;
> }
>
> -u32 vlv_gpio_nc_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
> - SB_CRRDDA_NP, reg, &val);
> - return val;
> -}
> -
> void vlv_gpio_nc_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> {
> vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPIO_NC,
> @@ -157,34 +149,6 @@ void vlv_cck_write(struct drm_i915_private *dev_priv,
> u32 reg, u32 val)
> SB_CRWRDA_NP, reg, &val);
> }
>
> -u32 vlv_ccu_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
> - SB_CRRDDA_NP, reg, &val);
> - return val;
> -}
> -
> -void vlv_ccu_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> -{
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_CCU,
> - SB_CRWRDA_NP, reg, &val);
> -}
> -
> -u32 vlv_gps_core_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
> - SB_CRRDDA_NP, reg, &val);
> - return val;
> -}
> -
> -void vlv_gps_core_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> -{
> - vlv_sideband_rw(dev_priv, PCI_DEVFN(2, 0), IOSF_PORT_GPS_CORE,
> - SB_CRWRDA_NP, reg, &val);
> -}
> -
> u32 vlv_dpio_read(struct drm_i915_private *dev_priv, enum pipe pipe, int reg)
> {
> u32 val = 0;
> @@ -267,14 +231,6 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
> u16 reg, u32 value,
> }
> }
>
> -u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg)
> -{
> - u32 val = 0;
> - vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRRDDA_NP,
> - reg, &val);
> - return val;
> -}
> -
> void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val)
> {
> vlv_sideband_rw(dev_priv, DPIO_DEVFN, IOSF_PORT_FLISDSI, SB_CRWRDA_NP,
> --
> 1.7.10.4
>
--
Jani Nikula, Intel Open Source Technology Center
[PATCH V8 03/14] drm/bridge: make bridge registration independent of drm flow
On Tue, Dec 2, 2014 at 11:31 AM, Ajay kumar wrote:
> On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar
> wrote:
>> Currently, third party bridge drivers(ptn3460) are dependent
>> on the corresponding encoder driver init, since bridge driver
>> needs a drm_device pointer to finish drm initializations.
>> The encoder driver passes the drm_device pointer to the
>> bridge driver. Because of this dependency, third party drivers
>> like ptn3460 doesn't adhere to the driver model.
>>
>> In this patch, we reframe the bridge registration framework
>> so that bridge initialization is split into 2 steps, and
>> bridge registration happens independent of drm flow:
>> --Step 1: gather all the bridge settings independent of drm and
>> add the bridge onto a global list of bridges.
>> --Step 2: when the encoder driver is probed, call drm_bridge_attach
>> for the corresponding bridge so that the bridge receives
>> drm_device pointer and continues with connector and other
>> drm initializations.
>>
>> The old set of bridge helpers are removed, and a set of new helpers
>> are added to accomplish the 2 step initialization.
>>
>> The bridge devices register themselves onto global list of bridges
>> when they get probed by calling "drm_bridge_add".
>>
>> The parent encoder driver waits till the bridge is available
>> in the lookup table(by calling "of_drm_find_bridge") and then
>> continues with its initialization.
>>
>> The encoder driver should also call "drm_bridge_attach" to pass
>> on the drm_device to the bridge object.
>>
>> drm_bridge_attach inturn calls "bridge->funcs->attach" so that
>> bridge can continue with drm related initializations.
>>
>> Signed-off-by: Ajay Kumar
>> ---
>> drivers/gpu/drm/Makefile |2 +-
>> drivers/gpu/drm/bridge/ptn3460.c | 27 +-
>> drivers/gpu/drm/drm_bridge.c | 91
>>
>> drivers/gpu/drm/drm_crtc.c | 65 ---
>> drivers/gpu/drm/msm/hdmi/hdmi.c|7 +--
>> drivers/gpu/drm/msm/hdmi/hdmi.h|1 +
>> drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |7 ++-
>> drivers/gpu/drm/sti/sti_hda.c | 10 +---
>> drivers/gpu/drm/sti/sti_hdmi.c | 10 +---
>> include/drm/bridge/ptn3460.h |8 +++
>> include/drm/drm_crtc.h | 26 -
>> 11 files changed, 136 insertions(+), 118 deletions(-)
>> create mode 100644 drivers/gpu/drm/drm_bridge.c
>>
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 9292a76..00f97a5 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
>> drm_info.o drm_debugfs.o drm_encoder_slave.o \
>> drm_trace_points.o drm_global.o drm_prime.o \
>> drm_rect.o drm_vma_manager.o drm_flip_work.o \
>> - drm_modeset_lock.o
>> + drm_modeset_lock.o drm_bridge.o
>>
>> drm-$(CONFIG_COMPAT) += drm_ioc32.o
>> drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>> diff --git a/drivers/gpu/drm/bridge/ptn3460.c
>> b/drivers/gpu/drm/bridge/ptn3460.c
>> index a2ddc8d..4a818c1 100644
>> --- a/drivers/gpu/drm/bridge/ptn3460.c
>> +++ b/drivers/gpu/drm/bridge/ptn3460.c
>> @@ -176,24 +176,11 @@ static void ptn3460_post_disable(struct drm_bridge
>> *bridge)
>> {
>> }
>>
>> -static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
>> -{
>> - struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
>> -
>> - drm_bridge_cleanup(bridge);
>> - if (gpio_is_valid(ptn_bridge->gpio_pd_n))
>> - gpio_free(ptn_bridge->gpio_pd_n);
>> - if (gpio_is_valid(ptn_bridge->gpio_rst_n))
>> - gpio_free(ptn_bridge->gpio_rst_n);
>> - /* Nothing else to free, we've got devm allocated memory */
>> -}
>> -
>> static struct drm_bridge_funcs ptn3460_bridge_funcs = {
>> .pre_enable = ptn3460_pre_enable,
>> .enable = ptn3460_enable,
>> .disable = ptn3460_disable,
>> .post_disable = ptn3460_post_disable,
>> - .destroy = ptn3460_bridge_destroy,
>> };
>>
>> static int ptn3460_get_modes(struct drm_connector *connector)
>> @@ -314,7 +301,7 @@ int ptn3460_init(struct drm_device *dev, struct
>> drm_encoder *encoder,
>> }
>>
>> ptn_bridge->bridge.funcs = &ptn3460_bridge_funcs;
>> - ret = drm_bridge_init(dev, &ptn_bridge->bridge);
>> + ret = drm_bridge_attach(dev, &ptn_bridge->bridge);
>> if (ret) {
>> DRM_ERROR("Failed to initialize bridge with drm\n");
>> goto err;
>> @@ -343,3 +330,15 @@ err:
>> return ret;
>> }
>> EXPORT_SYMBOL(ptn3460_init);
>> +
>> +void ptn3460_destroy(struct drm_bridge *bridge)
>> +{
>> + struct ptn3460_bridge *ptn_bridge = bridge->driver_private;
>> +
>> + if (gpio_is_valid(ptn_bridge->gpio_pd_n))
>> +
[PATCH 7/20] drm/i915: fix misspelling of current function in string
On Sun, 07 Dec 2014, Julia Lawall wrote:
> Replace a misspelled function name by %s and then __func__.
>
> This was done using Coccinelle, including the use of Levenshtein distance,
> as proposed by Rasmus Villemoes.
>
> Signed-off-by: Julia Lawall
>
> ---
> The semantic patch is difficult to summarize, but is available in the cover
> letter of this patch series.
>
> The message is sort of ambiguous, but I assume that it is intended to refer
> to the function in which the problem is detected.
Hmm, DRM_DEBUG prints __func__ too.
Jani.
>
> drivers/gpu/drm/i915/i915_gem.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d2ba315..fa21d1c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4335,7 +4335,7 @@ i915_gem_unpin_ioctl(struct drm_device *dev, void *data,
> }
>
> if (obj->pin_filp != file) {
> - DRM_DEBUG("Not pinned by caller in i915_gem_pin_ioctl(): %d\n",
> + DRM_DEBUG("Not pinned by caller in %s(): %d\n", __func__,
> args->handle);
> ret = -EINVAL;
> goto out;
>
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] gpu: drm: i915: intel_dsi_cmd.c: Remove unused function
On Sun, 07 Dec 2014, Rickard Strandqvist wrote:
> Remove the function dsi_hs_mode_enable() that is not used anywhere.
Please don't.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/i915/intel_dsi_cmd.c | 21 -
> drivers/gpu/drm/i915/intel_dsi_cmd.h |2 --
> 2 files changed, 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.c
> b/drivers/gpu/drm/i915/intel_dsi_cmd.c
> index f4767fd..71addcc 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_cmd.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_cmd.c
> @@ -103,27 +103,6 @@ enum dsi_type {
> DSI_GENERIC,
> };
>
> -/* enable or disable command mode hs transmissions */
> -void dsi_hs_mode_enable(struct intel_dsi *intel_dsi, bool enable)
> -{
> - struct drm_encoder *encoder = &intel_dsi->base.base;
> - struct drm_device *dev = encoder->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
> - enum pipe pipe = intel_crtc->pipe;
> - u32 temp;
> - u32 mask = DBI_FIFO_EMPTY;
> -
> - if (wait_for((I915_READ(MIPI_GEN_FIFO_STAT(pipe)) & mask) == mask, 50))
> - DRM_ERROR("Timeout waiting for DBI FIFO empty\n");
> -
> - temp = I915_READ(MIPI_HS_LP_DBI_ENABLE(pipe));
> - temp &= DBI_HS_LP_MODE_MASK;
> - I915_WRITE(MIPI_HS_LP_DBI_ENABLE(pipe), enable ? DBI_HS_MODE :
> DBI_LP_MODE);
> -
> - intel_dsi->hs = enable;
> -}
> -
> static int dsi_vc_send_short(struct intel_dsi *intel_dsi, int channel,
>u8 data_type, u16 data)
> {
> diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.h
> b/drivers/gpu/drm/i915/intel_dsi_cmd.h
> index 46aa1ac..7ad54c0 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_cmd.h
> +++ b/drivers/gpu/drm/i915/intel_dsi_cmd.h
> @@ -36,8 +36,6 @@
> #define DPI_LP_MODE_EN false
> #define DPI_HS_MODE_EN true
>
> -void dsi_hs_mode_enable(struct intel_dsi *intel_dsi, bool enable);
> -
> int dsi_vc_dcs_write(struct intel_dsi *intel_dsi, int channel,
>const u8 *data, int len);
>
> --
> 1.7.10.4
>
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] gpu: drm: i915: intel_dsi_pll.c: Remove unused function
On Mon, 08 Dec 2014, Rickard Strandqvist wrote:
> Remove the function dsi_rr_formula() that is not used anywhere.
Please don't.
BR,
Jani.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/gpu/drm/i915/intel_dsi_pll.c | 83
> +-
> 1 file changed, 1 insertion(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
> b/drivers/gpu/drm/i915/intel_dsi_pll.c
> index fa7a6ca..20086e8 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_pll.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
> @@ -50,88 +50,7 @@ static const u32 lfsr_converts[] = {
> 71, 35 /* 91 - 92 */
> };
>
> -#ifdef DSI_CLK_FROM_RR
> -
> -static u32 dsi_rr_formula(const struct drm_display_mode *mode,
> - int pixel_format, int video_mode_format,
> - int lane_count, bool eotp)
> -{
> - u32 bpp;
> - u32 hactive, vactive, hfp, hsync, hbp, vfp, vsync, vbp;
> - u32 hsync_bytes, hbp_bytes, hactive_bytes, hfp_bytes;
> - u32 bytes_per_line, bytes_per_frame;
> - u32 num_frames;
> - u32 bytes_per_x_frames, bytes_per_x_frames_x_lanes;
> - u32 dsi_bit_clock_hz;
> - u32 dsi_clk;
> -
> - switch (pixel_format) {
> - default:
> - case VID_MODE_FORMAT_RGB888:
> - case VID_MODE_FORMAT_RGB666_LOOSE:
> - bpp = 24;
> - break;
> - case VID_MODE_FORMAT_RGB666:
> - bpp = 18;
> - break;
> - case VID_MODE_FORMAT_RGB565:
> - bpp = 16;
> - break;
> - }
> -
> - hactive = mode->hdisplay;
> - vactive = mode->vdisplay;
> - hfp = mode->hsync_start - mode->hdisplay;
> - hsync = mode->hsync_end - mode->hsync_start;
> - hbp = mode->htotal - mode->hsync_end;
> -
> - vfp = mode->vsync_start - mode->vdisplay;
> - vsync = mode->vsync_end - mode->vsync_start;
> - vbp = mode->vtotal - mode->vsync_end;
> -
> - hsync_bytes = DIV_ROUND_UP(hsync * bpp, 8);
> - hbp_bytes = DIV_ROUND_UP(hbp * bpp, 8);
> - hactive_bytes = DIV_ROUND_UP(hactive * bpp, 8);
> - hfp_bytes = DIV_ROUND_UP(hfp * bpp, 8);
> -
> - bytes_per_line = DSI_HSS_PACKET_SIZE + hsync_bytes +
> - DSI_HSA_PACKET_EXTRA_SIZE + DSI_HSE_PACKET_SIZE +
> - hbp_bytes + DSI_HBP_PACKET_EXTRA_SIZE +
> - hactive_bytes + DSI_HACTIVE_PACKET_EXTRA_SIZE +
> - hfp_bytes + DSI_HFP_PACKET_EXTRA_SIZE;
> -
> - /*
> - * XXX: Need to accurately calculate LP to HS transition timeout and add
> - * it to bytes_per_line/bytes_per_frame.
> - */
> -
> - if (eotp && video_mode_format == VIDEO_MODE_BURST)
> - bytes_per_line += DSI_EOTP_PACKET_SIZE;
> -
> - bytes_per_frame = vsync * bytes_per_line + vbp * bytes_per_line +
> - vactive * bytes_per_line + vfp * bytes_per_line;
> -
> - if (eotp &&
> - (video_mode_format == VIDEO_MODE_NON_BURST_WITH_SYNC_PULSE ||
> - video_mode_format == VIDEO_MODE_NON_BURST_WITH_SYNC_EVENTS))
> - bytes_per_frame += DSI_EOTP_PACKET_SIZE;
> -
> - num_frames = drm_mode_vrefresh(mode);
> - bytes_per_x_frames = num_frames * bytes_per_frame;
> -
> - bytes_per_x_frames_x_lanes = bytes_per_x_frames / lane_count;
> -
> - /* the dsi clock is divided by 2 in the hardware to get dsi ddr clock */
> - dsi_bit_clock_hz = bytes_per_x_frames_x_lanes * 8;
> - dsi_clk = dsi_bit_clock_hz / 1000;
> -
> - if (eotp && video_mode_format == VIDEO_MODE_BURST)
> - dsi_clk *= 2;
> -
> - return dsi_clk;
> -}
> -
> -#else
> +#ifndef DSI_CLK_FROM_RR
>
> /* Get DSI clock from pixel clock */
> static u32 dsi_clk_from_pclk(u32 pclk, int pixel_format, int lane_count)
> --
> 1.7.10.4
>
--
Jani Nikula, Intel Open Source Technology Center
[PATCH] gpu: drm: i915: intel_dp.c: Remove unused function
On Sun, Dec 07, 2014 at 10:36:10PM +0100, Rickard Strandqvist wrote:
> Remove the function intel_dp_set_drrs_state() that is not used anywhere.
>
> This was partially found by using a static code analysis program called
> cppcheck.
>
> Signed-off-by: Rickard Strandqvist
Ok I've merged one of these patches here for old stale code, but all the
others are in areas where there's a lot of stuff going on and we'll likely
use these functions again. So decided to drop those patches.
If you want to keep working on drm stuff I'd highly appreciate it. We have
a list of intro tasks which might be interesting:
http://www.x.org/wiki/DRMJanitors/
Nuking all the UMS checks might be a good one, we've already started with
that. And #intel-gfx irc on freenode is always a good place to hang out
and ask questions.
Cheers, Daniel
> ---
> drivers/gpu/drm/i915/intel_dp.c | 89
> --
> drivers/gpu/drm/i915/intel_drv.h |1 -
> 2 files changed, 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5ad45bf..6df948b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4810,95 +4810,6 @@ intel_dp_init_panel_power_sequencer_registers(struct
> drm_device *dev,
> I915_READ(pp_div_reg));
> }
>
> -void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate)
> -{
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_encoder *encoder;
> - struct intel_dp *intel_dp = NULL;
> - struct intel_crtc_config *config = NULL;
> - struct intel_crtc *intel_crtc = NULL;
> - struct intel_connector *intel_connector = dev_priv->drrs.connector;
> - u32 reg, val;
> - enum edp_drrs_refresh_rate_type index = DRRS_HIGH_RR;
> -
> - if (refresh_rate <= 0) {
> - DRM_DEBUG_KMS("Refresh rate should be positive non-zero.\n");
> - return;
> - }
> -
> - if (intel_connector == NULL) {
> - DRM_DEBUG_KMS("DRRS supported for eDP only.\n");
> - return;
> - }
> -
> - /*
> - * FIXME: This needs proper synchronization with psr state. But really
> - * hard to tell without seeing the user of this function of this code.
> - * Check locking and ordering once that lands.
> - */
> - if (INTEL_INFO(dev)->gen < 8 && intel_edp_is_psr_enabled(dev)) {
> - DRM_DEBUG_KMS("DRRS is disabled as PSR is enabled\n");
> - return;
> - }
> -
> - encoder = intel_attached_encoder(&intel_connector->base);
> - intel_dp = enc_to_intel_dp(&encoder->base);
> - intel_crtc = encoder->new_crtc;
> -
> - if (!intel_crtc) {
> - DRM_DEBUG_KMS("DRRS: intel_crtc not initialized\n");
> - return;
> - }
> -
> - config = &intel_crtc->config;
> -
> - if (intel_dp->drrs_state.type < SEAMLESS_DRRS_SUPPORT) {
> - DRM_DEBUG_KMS("Only Seamless DRRS supported.\n");
> - return;
> - }
> -
> - if (intel_connector->panel.downclock_mode->vrefresh == refresh_rate)
> - index = DRRS_LOW_RR;
> -
> - if (index == intel_dp->drrs_state.refresh_rate_type) {
> - DRM_DEBUG_KMS(
> - "DRRS requested for previously set RR...ignoring\n");
> - return;
> - }
> -
> - if (!intel_crtc->active) {
> - DRM_DEBUG_KMS("eDP encoder disabled. CRTC not Active\n");
> - return;
> - }
> -
> - if (INTEL_INFO(dev)->gen > 6 && INTEL_INFO(dev)->gen < 8) {
> - reg = PIPECONF(intel_crtc->config.cpu_transcoder);
> - val = I915_READ(reg);
> - if (index > DRRS_HIGH_RR) {
> - val |= PIPECONF_EDP_RR_MODE_SWITCH;
> - intel_dp_set_m_n(intel_crtc);
> - } else {
> - val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
> - }
> - I915_WRITE(reg, val);
> - }
> -
> - /*
> - * mutex taken to ensure that there is no race between differnt
> - * drrs calls trying to update refresh rate. This scenario may occur
> - * in future when idleness detection based DRRS in kernel and
> - * possible calls from user space to set differnt RR are made.
> - */
> -
> - mutex_lock(&intel_dp->drrs_state.mutex);
> -
> - intel_dp->drrs_state.refresh_rate_type = index;
> -
> - mutex_unlock(&intel_dp->drrs_state.mutex);
> -
> - DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate);
> -}
> -
> static struct drm_display_mode *
> intel_dp_drrs_init(struct intel_digital_port *intel_dig_port,
> struct intel_connector *intel_connector,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index ba71522..6ad239d 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -941,7 +941,6 @@ void intel_edp_panel_on(struct inte
[Intel-gfx] [PATCH] gpu: drm: i915: intel_display.c: Remove unused function
2014-12-08 6:42 GMT-02:00 Daniel Vetter : > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote: >> Remove the function intel_output_name() that is not used anywhere. >> >> This was partially found by using a static code analysis program called >> cppcheck. >> >> Signed-off-by: Rickard Strandqvist > spectrumdigital.se> > > Queued for 3.20, thanks for the patch. This function was created for the "DDI personality" patches. We merged the function but never ended up merging the patch containing the callers... > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni
[PATCH 1/2] drm/msm: Initial add eDP support in msm drm driver (V2)
t; +
> + mutex_lock(&ctrl->dev_mutex);
> +
> + if (ctrl->edid) {
> + if (edid) {
> + DBG("Just return edid buffer");
> + *edid = ctrl->edid;
> + }
> + goto unlock_ret;
> + }
Is there a way to invalidate an existing EDID?
> +
> + if (!ctrl->power_on) {
> + if (!ctrl->cont_splash)
> + edp_ctrl_phy_aux_enable(ctrl, 1);
> + edp_ctrl_irq_enable(ctrl, 1);
> + }
> +
> + ret = drm_dp_link_probe(ctrl->drm_aux, &ctrl->dp_link);
> + if (ret) {
> + pr_err("%s: read dpcd cap failed, %d\n", __func__, ret);
> + goto disable_ret;
> + }
> +
> + /* Initialize link rate as panel max link rate */
> + ctrl->link_rate = drm_dp_link_rate_to_bw_code(ctrl->dp_link.rate);
There's a lot of code here that should probably be a separate function
rather than be called as part of retrieving the EDID.
> +int msm_edp_ctrl_timing_cfg(struct edp_ctrl *ctrl,
> + struct drm_display_mode *mode, struct drm_display_info *info)
Can mode and info be const?
> +{
> + u32 hstart_from_sync, vstart_from_sync;
> + u32 data;
> + int ret = 0;
> +
[...]
> +
> + vstart_from_sync = mode->vtotal - mode->vsync_start;
> + hstart_from_sync = (mode->htotal - mode->hsync_start);
No need for the parentheses.
> diff --git a/drivers/gpu/drm/msm/edp/edp_phy.c
> b/drivers/gpu/drm/msm/edp/edp_phy.c
[...]
> +bool msm_edp_phy_ready(struct edp_phy *phy)
> +{
> + u32 status;
> + int cnt;
> +
> + cnt = 100;
> + while (--cnt) {
> + status = edp_read(phy->base +
> + REG_EDP_PHY_GLB_PHY_STATUS);
> + if (status & 0x01)
Can you add a define for 0x01?
> + break;
> + usleep_range(500, 1000);
> + }
> +
> + if (cnt <= 0) {
This is a better version than above, except that cnt can never be
negative. It will be zero upon timeout.
> + pr_err("%s: PHY NOT ready\n", __func__);
> + return false;
> + } else {
> + return true;
> + }
> +}
> +
> +void msm_edp_phy_ctrl(struct edp_phy *phy, int enable)
> +{
> + DBG("enable=%d", enable);
> + if (enable) {
> + /* Reset */
> + edp_write(phy->base + REG_EDP_PHY_CTRL, 0x005); /* bit 0, 2 */
> + wmb();
> + usleep_range(500, 1000);
> + edp_write(phy->base + REG_EDP_PHY_CTRL, 0x000);
> + edp_write(phy->base + REG_EDP_PHY_GLB_PD_CTL, 0x3f);
> + edp_write(phy->base + REG_EDP_PHY_GLB_CFG, 0x1);
> + } else {
> + edp_write(phy->base + REG_EDP_PHY_GLB_PD_CTL, 0xc0);
> + }
Please, also add defines for the values here. It's impossible to tell
from the code what this does or what might need fixing if there was a
bug.
> +void msm_edp_phy_lane_power_ctrl(struct edp_phy *phy, int up, int max_lane)
bool for up? And unsigned int for max_lane?
> +{
> + int i;
This could also be unsigned int.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/8f94faa8/attachment-0001.sig>
[PATCH 2/2] drm/msm: Add the eDP connector in msm drm driver
On Fri, Dec 05, 2014 at 04:30:01PM -0500, Hai Li wrote:
> Modified the hard-coded hdmi connector/encoder implementations in msm drm
> driver to support both edp and hdmi.
s/hdmi/HDMI/, s/msm/MSM/, s/drm/DRM/, s/edp/eDP/
[...]
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
[...]
> @@ -177,7 +180,28 @@ static void mdp5_encoder_mode_set(struct drm_encoder
> *encoder,
> /* probably need to get DATA_EN polarity from panel.. */
>
> dtv_hsync_skew = 0; /* get this from panel? */
> - format = 0x213f; /* get this from panel? */
> +
> + /* Get color format from panel, default is 8bpc */
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> + if (connector->encoder == encoder) {
> + switch (connector->display_info.bpc) {
> + case 4:
> + format |= 0;
> + break;
> + case 5:
> + format |= 0x15;
> + break;
> + case 6:
> + format |= 0x2A;
> + break;
> + case 8:
> + default:
> + format |= 0x3F;
> + break;
> + }
> + break;
I suppose that it might be obvious from the above switch statement, but
having symbolic names for the values of format might still be good for
readability.
> + }
> + }
>
> hsync_start_x = (mode->htotal - mode->hsync_start);
> hsync_end_x = mode->htotal - (mode->hsync_start - mode->hdisplay) - 1;
> @@ -187,6 +211,16 @@ static void mdp5_encoder_mode_set(struct drm_encoder
> *encoder,
> display_v_start = (mode->vtotal - mode->vsync_start) * mode->htotal +
> dtv_hsync_skew;
> display_v_end = vsync_period - ((mode->vsync_start - mode->vdisplay) *
> mode->htotal) + dtv_hsync_skew - 1;
>
> + /*
> + * For edp only:
> + * DISPLAY_V_START = (VBP * HCYCLE) + HBP
> + * DISPLAY_V_END = (VBP + VACTIVE) * HCYCLE - 1 - HFP
> + */
> + if (mdp5_encoder->intf_id == INTF_eDP) {
> + display_v_start += (mode->htotal - mode->hsync_start);
> + display_v_end -= (mode->hsync_start - mode->hdisplay);
No need for the parentheses.
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
[...]
> struct drm_device *dev = mdp5_kms->dev;
> struct msm_drm_private *priv = dev->dev_private;
> - struct drm_encoder *encoder;
> + struct drm_encoder *edp_encoder = NULL, *hdmi_encoder = NULL;
Can't you simply reuse encoder? It's scope is limited to the
conditionals, so no need to have two separate variables.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/69a9232a/attachment.sig>
[PATCH 1/2] drm/exynos: fimd: Remove drm_dev and pipe members from fimd_context
On 2014ë
12ì 07ì¼ 21:04, Ajay Kumar wrote:
> ctx->drm_dev is unnecessary since it can be easily accessed
> via ctx->manager->drm_dev. Even the pipe variable inside
> fimd_context is redundant. Cleaning up the same.
Already applied.
Thanks,
Inki Dae
>
> Signed-off-by: Ajay Kumar
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index e5810d1..157f4dd 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -159,7 +159,6 @@ struct fimd_win_data {
> struct fimd_context {
> struct exynos_drm_manager manager;
> struct device *dev;
> - struct drm_device *drm_dev;
> struct clk *bus_clk;
> struct clk *lcd_clk;
> void __iomem*regs;
> @@ -174,7 +173,6 @@ struct fimd_context {
> u32 i80ifcon;
> booli80_if;
> boolsuspended;
> - int pipe;
> wait_queue_head_t wait_vsync_queue;
> atomic_twait_vsync_event;
> atomic_twin_updated;
> @@ -298,17 +296,17 @@ static int fimd_mgr_initialize(struct
> exynos_drm_manager *mgr,
> struct exynos_drm_private *priv;
> priv = drm_dev->dev_private;
>
> - mgr->drm_dev = ctx->drm_dev = drm_dev;
> - mgr->pipe = ctx->pipe = priv->pipe++;
> + mgr->drm_dev = drm_dev;
> + mgr->pipe = priv->pipe++;
>
> /* attach this sub driver to iommu mapping if supported. */
> - if (is_drm_iommu_supported(ctx->drm_dev)) {
> + if (is_drm_iommu_supported(mgr->drm_dev)) {
> /*
>* If any channel is already active, iommu will throw
>* a PAGE FAULT when enabled. So clear any channel if enabled.
>*/
> fimd_clear_channel(mgr);
> - drm_iommu_attach_device(ctx->drm_dev, ctx->dev);
> + drm_iommu_attach_device(mgr->drm_dev, ctx->dev);
> }
>
> return 0;
> @@ -319,8 +317,8 @@ static void fimd_mgr_remove(struct exynos_drm_manager
> *mgr)
> struct fimd_context *ctx = mgr_to_fimd(mgr);
>
> /* detach this sub driver from iommu mapping if supported. */
> - if (is_drm_iommu_supported(ctx->drm_dev))
> - drm_iommu_detach_device(ctx->drm_dev, ctx->dev);
> + if (is_drm_iommu_supported(mgr->drm_dev))
> + drm_iommu_detach_device(mgr->drm_dev, ctx->dev);
> }
>
> static u32 fimd_calc_clkdiv(struct fimd_context *ctx,
> @@ -1001,7 +999,7 @@ static void fimd_te_handler(struct exynos_drm_manager
> *mgr)
> struct fimd_context *ctx = mgr_to_fimd(mgr);
>
> /* Checks the crtc is detached already from encoder */
> - if (ctx->pipe < 0 || !ctx->drm_dev)
> + if (mgr->pipe < 0 || !mgr->drm_dev)
> return;
>
> /*
> @@ -1018,7 +1016,7 @@ static void fimd_te_handler(struct exynos_drm_manager
> *mgr)
> }
>
> if (test_bit(0, &ctx->irq_flags))
> - drm_handle_vblank(ctx->drm_dev, ctx->pipe);
> + drm_handle_vblank(mgr->drm_dev, mgr->pipe);
> }
>
> static struct exynos_drm_manager_ops fimd_manager_ops = {
> @@ -1047,17 +1045,19 @@ static irqreturn_t fimd_irq_handler(int irq, void
> *dev_id)
> writel(clear_bit, ctx->regs + VIDINTCON1);
>
> /* check the crtc is detached already from encoder */
> - if (ctx->pipe < 0 || !ctx->drm_dev)
> + if (ctx->manager.pipe < 0 || !ctx->manager.drm_dev)
> goto out;
>
> if (ctx->i80_if) {
> - exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
> + exynos_drm_crtc_finish_pageflip(ctx->manager.drm_dev,
> + ctx->manager.pipe);
>
> /* Exits triggering mode */
> atomic_set(&ctx->triggering, 0);
> } else {
> - drm_handle_vblank(ctx->drm_dev, ctx->pipe);
> - exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
> + drm_handle_vblank(ctx->manager.drm_dev, ctx->manager.pipe);
> + exynos_drm_crtc_finish_pageflip(ctx->manager.drm_dev,
> + ctx->manager.pipe);
>
> /* set wait vsync event to zero and wake up queue. */
> if (atomic_read(&ctx->wait_vsync_event)) {
>
[PATCH V3] drm/exynos: Add DECON driver
On 2014ë
12ì 07ì¼ 21:04, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video signals using pixel data.
>
> DECON driver can be used to drive 2 different interfaces on Exynos7:
> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>
> The existing FIMD driver code was used as a template to create
> DECON driver. Only DECON-INT is supported as of now, and
> DECON-EXT support will be added later.
>
> Signed-off-by: Akshu Agrawal
> Signed-off-by: Ajay Kumar
> ---
> Changes since V1:
> -- Address comments from Pankaj and do few cleanups.
> Changes since V2:
> -- Address more comments from Pankaj and cleanup.
>
> .../devicetree/bindings/video/exynos7-decon.txt| 67 ++
> drivers/gpu/drm/exynos/Kconfig | 13 +-
> drivers/gpu/drm/exynos/Makefile|1 +
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1042
> drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
> drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
> include/video/exynos7_decon.h | 346 +++
> 7 files changed, 1471 insertions(+), 3 deletions(-)
> create mode 100644
Documentation/devicetree/bindings/video/exynos7-decon.txt
> create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
> create mode 100644 include/video/exynos7_decon.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
> new file mode 100644
> index 000..14db519
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
> @@ -0,0 +1,67 @@
> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
> +
> +DECON (Display and Enhancement Controller) is the Display Controller
for the
> +Exynos7 series of SoCs which transfers the image data from a video memory
> +buffer to an external LCD interface.
> +
> +Required properties:
> +- compatible: value should be "samsung,exynos7-decon";
> +
> +- reg: physical base address and length of the DECON registers set.
> +
> +- interrupt-parent: should be the phandle of the decon controller's
> + parent interrupt controller.
> +
> +- interrupts: should contain a list of all DECON IP block interrupts
in the
> + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
> + format depends on the interrupt controller used.
> +
> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
> + "lcd_sys", in the same order as they were listed in the interrupts
> +property.
> +
> +- pinctrl-0: pin control group to be used for this controller.
> +
> +- pinctrl-names: must contain a "default" entry.
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: list of clock names sorted in the same order as the clocks
> + property. Must contain "pclk_decon0", "aclk_decon0",
> +"decon0_eclk", "decon0_vclk".
Should the DECON driver really care about decon0_eclk and decon0_vclk?
If so then What is the purpose of these special clocks? I'm not sure
that these clocks should be cared by driver. Until now, Exynos driver
has cared about only video source and core source clocks.
Can you give me more details about the use of the special clocks?
> +
> +Optional Properties:
> +- samsung,power-domain: a phandle to DECON power domain node.
> +- display-timings: timing settings for FIMD, as described in document
[1].
> + Can be used in case timings cannot be provided otherwise
> + or to override timings provided by the panel.
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +
> +Example:
> +
> +SoC specific DT entry:
> +
> + decon at 1393 {
> + compatible = "samsung,exynos7-decon";
> + interrupt-parent = <&combiner>;
> + reg = <0x1393 0x1000>;
> + interrupt-names = "lcd_sys", "vsync", "fifo";
> + interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
> + clocks = <&clock_disp PCLK_DECON_INT>,
> + <&clock_disp ACLK_DECON_INT>,
> + <&clock_disp SCLK_DECON_INT_ECLK>,
> + <&clock_disp SCLK_DECON_INT_EXTCLKPLL>;
> + clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
> + "decon0_vclk";
> + status = "disabled";
> + };
> +
> +Board specific DT entry:
> +
> + decon at 1393 {
> + pinctrl-0 = <&lcd_clk &pwm1_out>;
> + pinctrl-names = "default";
> + status = "okay";
> + };
> diff --git a/drivers/gpu/drm/exynos/Kconfig
b/drivers/gpu/drm/exynos/Kconfig
> inde
[PATCH 7/20] drm/i915: fix misspelling of current function in string
On Mon, Dec 08, 2014 at 12:24:27PM +0200, Jani Nikula wrote: > On Sun, 07 Dec 2014, Julia Lawall wrote: > > Replace a misspelled function name by %s and then __func__. > > > > This was done using Coccinelle, including the use of Levenshtein distance, > > as proposed by Rasmus Villemoes. > > > > Signed-off-by: Julia Lawall > > > > --- > > The semantic patch is difficult to summarize, but is available in the cover > > letter of this patch series. > > > > The message is sort of ambiguous, but I assume that it is intended to refer > > to the function in which the problem is detected. > > Hmm, DRM_DEBUG prints __func__ too. We've killed the pin ioctl for 3.20 hence didn't even bother to come up with an opinion ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH] gpu: drm: i915: intel_display.c: Remove unused function
On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote: > 2014-12-08 6:42 GMT-02:00 Daniel Vetter : > > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote: > >> Remove the function intel_output_name() that is not used anywhere. > >> > >> This was partially found by using a static code analysis program called > >> cppcheck. > >> > >> Signed-off-by: Rickard Strandqvist >> spectrumdigital.se> > > > > Queued for 3.20, thanks for the patch. > > This function was created for the "DDI personality" patches. We merged > the function but never ended up merging the patch containing the > callers... Oops, I've thought this is a renmant from the very first days of kms that somehow stuck around. That's what I get for once not using git blame excessively :( Want me to drop the patch again? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 89331] Radeon 8670M in DRI_PRIME shows garbage in scene
https://bugzilla.kernel.org/show_bug.cgi?id=89331 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 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume
https://bugs.freedesktop.org/show_bug.cgi?id=86267 --- Comment #12 from stefanscheffler at gmx.net --- Doesn't help. Tested with 3.17.4 and 3.18.0. -- 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/20141208/e3c52fba/attachment.html>
[Bug 67790] error message on suspend and hibernate: *ERROR* Could not force DPM to low
https://bugs.freedesktop.org/show_bug.cgi?id=67790 --- Comment #2 from almos --- This is printed with my Barts GPU as well, which seems to indicate that the function is slightly misnamed. -- 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/20141208/f0e62425/attachment.html>
[Bug 89331] Radeon 8670M in DRI_PRIME shows garbage in scene
https://bugzilla.kernel.org/show_bug.cgi?id=89331 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- This is a limitation of prime at the moment. There is no cross device synchronization support yet. See also https://bugs.freedesktop.org/show_bug.cgi?id=76367 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 20/20] drm/radeon: fix misspelling of current function in string
On Sun, Dec 7, 2014 at 2:21 PM, Julia Lawall wrote:
> Replace a misspelled function name by %s and then __func__.
>
> This was done using Coccinelle, including the use of Levenshtein distance,
> as proposed by Rasmus Villemoes.
>
> Signed-off-by: Julia Lawall
Looks fine to me. For consistency, any chance you'd want to fix up
the other places that use function names directly with this style
patch?
Alex
>
> ---
> The semantic patch is difficult to summarize, but is available in the cover
> letter of this patch series.
>
> drivers/gpu/drm/radeon/cik.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index 6dcde37..24d5e43 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -7367,34 +7367,38 @@ int cik_irq_set(struct radeon_device *rdev)
> }
> if (atomic_read(&rdev->irq.ring_int[CAYMAN_RING_TYPE_CP1_INDEX])) {
> struct radeon_ring *ring =
> &rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX];
> - DRM_DEBUG("si_irq_set: sw int cp1\n");
> + DRM_DEBUG("%s: sw int cp1\n", __func__);
> if (ring->me == 1) {
> switch (ring->pipe) {
> case 0:
> cp_m1p0 |= TIME_STAMP_INT_ENABLE;
> break;
> default:
> - DRM_DEBUG("si_irq_set: sw int cp1 invalid
> pipe %d\n", ring->pipe);
> + DRM_DEBUG("%s: sw int cp1 invalid pipe %d\n",
> + __func__, ring->pipe);
> break;
> }
> } else {
> - DRM_DEBUG("si_irq_set: sw int cp1 invalid me %d\n",
> ring->me);
> + DRM_DEBUG("%s: sw int cp1 invalid me %d\n", __func__,
> + ring->me);
> }
> }
> if (atomic_read(&rdev->irq.ring_int[CAYMAN_RING_TYPE_CP2_INDEX])) {
> struct radeon_ring *ring =
> &rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX];
> - DRM_DEBUG("si_irq_set: sw int cp2\n");
> + DRM_DEBUG("%s: sw int cp2\n", __func__);
> if (ring->me == 1) {
> switch (ring->pipe) {
> case 0:
> cp_m1p0 |= TIME_STAMP_INT_ENABLE;
> break;
> default:
> - DRM_DEBUG("si_irq_set: sw int cp2 invalid
> pipe %d\n", ring->pipe);
> + DRM_DEBUG("%s: sw int cp2 invalid pipe %d\n",
> + __func__, ring->pipe);
> break;
> }
> } else {
> - DRM_DEBUG("si_irq_set: sw int cp2 invalid me %d\n",
> ring->me);
> + DRM_DEBUG("%s: sw int cp2 invalid me %d\n", __func__,
> + ring->me);
> }
> }
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atomic: fix potential null ptr on plane enable
When a plane is being enabled, plane->crtc has not been set yet. Use
plane->state->crtc.
Signed-off-by: Rob Clark
---
Looks like this is still missing on drm-next.. I probably forgot to
send it earlier.
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 4a78a77..bbdbe47 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -61,7 +61,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
*state,
struct drm_crtc_state *crtc_state;
if (plane->state->crtc) {
- crtc_state = state->crtc_states[drm_crtc_index(plane->crtc)];
+ crtc_state =
state->crtc_states[drm_crtc_index(plane->state->crtc)];
if (WARN_ON(!crtc_state))
return;
--
1.9.3
[PATCH 0/4] drm/msm: YUV suppport addition for MDP4 & MDP5
Hi, So this set of patches adds YUV support for MDP4 and MDP5. This only concerns the public planes (using ViG pipes). The fun part was to rebase things on top of atomic but things worked out fine. I was able to test this for MDP5 on a 8084 target. I cannot say the same for MDP4 for which I don't have a build based on atomic yet. The change is pretty similar to MDP5 though. Rgds, Stephane. Beeresh Gopal (1): drm/msm/mdp4: add YUV format support Stephane Viau (3): drm/msm/mdp: add register description for YUV support drm/msm/mdp: add common YUV information for MDP4/MDP5 drm/msm/mdp5: add NV12 support for MDP5 drivers/gpu/drm/msm/hdmi/hdmi.c | 149 ++--- drivers/gpu/drm/msm/hdmi/hdmi.h | 8 +- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 1 - drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h | 44 ++ drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 19 ++- drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 104 +-- drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 153 +++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 19 ++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 215 +++--- drivers/gpu/drm/msm/mdp/mdp_common.xml.h | 30 +++-- drivers/gpu/drm/msm/mdp/mdp_format.c | 108 +-- drivers/gpu/drm/msm/mdp/mdp_kms.h | 24 +++- drivers/gpu/drm/msm/msm_fb.c | 4 +- drivers/gpu/drm/msm/msm_kms.h | 2 + 14 files changed, 754 insertions(+), 126 deletions(-) -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/4] drm/msm/mdp: add register description for YUV support
YUV support addition implies that sub-modules of the ViG pipes
need to be configured: Color Space Converter (CSC) and Scaler are
the main components used to convert YUV to RGB data. Note that
the output of a pipe has to be in RGB888 format since only this
format is understood by the (layer) mixers.
Generated headers are kept in a separate change to ease the
actual driver's code review.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h | 44 +
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 153 +--
drivers/gpu/drm/msm/mdp/mdp_common.xml.h | 30 +++---
3 files changed, 205 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
index a4a7f8c..b815c9c 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h
@@ -72,6 +72,18 @@ enum mdp4_cursor_format {
CURSOR_XRGB = 2,
};
+enum mdp4_frame_format {
+ FRAME_LINEAR = 0,
+ FRAME_TILE_ARGB_4X4 = 1,
+ FRAME_TILE_YCBCR_420 = 2,
+};
+
+enum mdp4_scale_unit {
+ SCALE_FIR = 0,
+ SCALE_MN_PHASE = 1,
+ SCALE_PIXEL_RPT = 2,
+};
+
enum mdp4_dma {
DMA_P = 0,
DMA_S = 1,
@@ -637,6 +649,8 @@ static inline uint32_t REG_MDP4_PIPE_SRCP1_BASE(enum
mdp4_pipe i0) { return 0x00
static inline uint32_t REG_MDP4_PIPE_SRCP2_BASE(enum mdp4_pipe i0) { return
0x00020018 + 0x1*i0; }
+static inline uint32_t REG_MDP4_PIPE_SRCP3_BASE(enum mdp4_pipe i0) { return
0x0002001c + 0x1*i0; }
+
static inline uint32_t REG_MDP4_PIPE_SRC_STRIDE_A(enum mdp4_pipe i0) { return
0x00020040 + 0x1*i0; }
#define MDP4_PIPE_SRC_STRIDE_A_P0__MASK
0x
#define MDP4_PIPE_SRC_STRIDE_A_P0__SHIFT 0
@@ -720,7 +734,25 @@ static inline uint32_t
MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(uint32_t val)
}
#define MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT 0x0002
#define MDP4_PIPE_SRC_FORMAT_UNPACK_ALIGN_MSB 0x0004
+#define MDP4_PIPE_SRC_FORMAT_FETCH_PLANES__MASK
0x0018
+#define MDP4_PIPE_SRC_FORMAT_FETCH_PLANES__SHIFT 19
+static inline uint32_t MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(uint32_t val)
+{
+ return ((val) << MDP4_PIPE_SRC_FORMAT_FETCH_PLANES__SHIFT) &
MDP4_PIPE_SRC_FORMAT_FETCH_PLANES__MASK;
+}
#define MDP4_PIPE_SRC_FORMAT_SOLID_FILL
0x0040
+#define MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP__MASK 0x0c00
+#define MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP__SHIFT26
+static inline uint32_t MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(enum
mdp_chroma_samp_type val)
+{
+ return ((val) << MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP__SHIFT) &
MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP__MASK;
+}
+#define MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT__MASK
0x6000
+#define MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT__SHIFT 29
+static inline uint32_t MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(enum
mdp4_frame_format val)
+{
+ return ((val) << MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT__SHIFT) &
MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT__MASK;
+}
static inline uint32_t REG_MDP4_PIPE_SRC_UNPACK(enum mdp4_pipe i0) { return
0x00020054 + 0x1*i0; }
#define MDP4_PIPE_SRC_UNPACK_ELEM0__MASK 0x00ff
@@ -751,6 +783,18 @@ static inline uint32_t MDP4_PIPE_SRC_UNPACK_ELEM3(uint32_t
val)
static inline uint32_t REG_MDP4_PIPE_OP_MODE(enum mdp4_pipe i0) { return
0x00020058 + 0x1*i0; }
#define MDP4_PIPE_OP_MODE_SCALEX_EN0x0001
#define MDP4_PIPE_OP_MODE_SCALEY_EN0x0002
+#define MDP4_PIPE_OP_MODE_SCALEX_UNIT_SEL__MASK
0x000c
+#define MDP4_PIPE_OP_MODE_SCALEX_UNIT_SEL__SHIFT 2
+static inline uint32_t MDP4_PIPE_OP_MODE_SCALEX_UNIT_SEL(enum mdp4_scale_unit
val)
+{
+ return ((val) << MDP4_PIPE_OP_MODE_SCALEX_UNIT_SEL__SHIFT) &
MDP4_PIPE_OP_MODE_SCALEX_UNIT_SEL__MASK;
+}
+#define MDP4_PIPE_OP_MODE_SCALEY_UNIT_SEL__MASK
0x0030
+#define MDP4_PIPE_OP_MODE_SCALEY_UNIT_SEL__SHIFT 4
+static inline uint32_t MDP4_PIPE_OP_MODE_SCALEY_UNIT_SEL(enum mdp4_scale_unit
val)
+{
+ return ((val) << MDP4_PIPE_OP_MODE_SCALEY_UNIT_SEL__SHIFT) &
MDP4_PIPE_OP_MODE_SCALEY_UNIT_SEL__MASK;
+}
#define MDP4_PIPE_OP_MODE_SRC_YCBCR0x0200
#define MDP4_PIPE_OP_MODE_DST_YCBCR0x0400
#define MDP4_PIPE_OP_MODE_CSC_EN 0x0800
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index e87ef55..26cdfd5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -88,13 +88,6 @@ enum mdp5_pack_3d {
PACK_3D_COL_INT = 3,
};
-enum mdp5_chroma_samp_type {
- CHROMA_RGB = 0,
[PATCH 2/4] drm/msm/mdp: add common YUV information for MDP4/MDP5
Both MDP4 and MDP5 share some code as far as YUV support is
concerned. This change adds this information and will be followed
by the actual MDP4 and MDP5 YUV support patches.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 19 --
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 19 --
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 -
drivers/gpu/drm/msm/mdp/mdp_format.c | 108 +++---
drivers/gpu/drm/msm/mdp/mdp_kms.h | 24 ++-
drivers/gpu/drm/msm/msm_fb.c | 2 +-
drivers/gpu/drm/msm/msm_kms.h | 2 +
7 files changed, 154 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
index cbd77bc..0a5c58b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h
@@ -175,14 +175,25 @@ irqreturn_t mdp4_irq(struct msm_kms *kms);
int mdp4_enable_vblank(struct msm_kms *kms, struct drm_crtc *crtc);
void mdp4_disable_vblank(struct msm_kms *kms, struct drm_crtc *crtc);
+static inline bool pipe_supports_yuv(enum mdp4_pipe pipe)
+{
+ switch (pipe) {
+ case VG1:
+ case VG2:
+ case VG3:
+ case VG4:
+ return true;
+ default:
+ return false;
+ }
+}
+
static inline
uint32_t mdp4_get_formats(enum mdp4_pipe pipe_id, uint32_t *pixel_formats,
uint32_t max_formats)
{
- /* TODO when we have YUV, we need to filter supported formats
-* based on pipe_id..
-*/
- return mdp_get_formats(pixel_formats, max_formats);
+ return mdp_get_formats(pixel_formats, max_formats,
+ !pipe_supports_yuv(pipe_id));
}
void mdp4_plane_install_properties(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index dd69c77..49d011e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -165,14 +165,25 @@ void mdp5_disable_vblank(struct msm_kms *kms, struct
drm_crtc *crtc);
int mdp5_irq_domain_init(struct mdp5_kms *mdp5_kms);
void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms);
+static inline bool pipe_supports_yuv(enum mdp5_pipe pipe)
+{
+ switch (pipe) {
+ case SSPP_VIG0:
+ case SSPP_VIG1:
+ case SSPP_VIG2:
+ case SSPP_VIG3:
+ return true;
+ default:
+ return false;
+ }
+}
+
static inline
uint32_t mdp5_get_formats(enum mdp5_pipe pipe, uint32_t *pixel_formats,
uint32_t max_formats)
{
- /* TODO when we have YUV, we need to filter supported formats
-* based on pipe id..
-*/
- return mdp_get_formats(pixel_formats, max_formats);
+ return mdp_get_formats(pixel_formats, max_formats,
+ !pipe_supports_yuv(pipe));
}
void mdp5_plane_install_properties(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 533df7c..9a57e87 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -18,8 +18,6 @@
#include "mdp5_kms.h"
-#define MAX_PLANE 4
-
struct mdp5_plane {
struct drm_plane base;
const char *name;
diff --git a/drivers/gpu/drm/msm/mdp/mdp_format.c
b/drivers/gpu/drm/msm/mdp/mdp_format.c
index e0a6ffb..f683433 100644
--- a/drivers/gpu/drm/msm/mdp/mdp_format.c
+++ b/drivers/gpu/drm/msm/mdp/mdp_format.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (c) 2014 The Linux Foundation. All rights reserved.
* Copyright (C) 2013 Red Hat
* Author: Rob Clark
*
@@ -19,7 +20,58 @@
#include "msm_drv.h"
#include "mdp_kms.h"
-#define FMT(name, a, r, g, b, e0, e1, e2, e3, alpha, tight, c, cnt) { \
+static struct csc_cfg csc_convert[CSC_MAX] = {
+ [CSC_RGB2RGB] = {
+ .type = CSC_RGB2RGB,
+ .matrix = {
+ 0x0200, 0x, 0x,
+ 0x, 0x0200, 0x,
+ 0x, 0x, 0x0200
+ },
+ .pre_bias = { 0x0, 0x0, 0x0 },
+ .post_bias ={ 0x0, 0x0, 0x0 },
+ .pre_clamp ={ 0x0, 0xff, 0x0, 0xff, 0x0, 0xff },
+ .post_clamp = { 0x0, 0xff, 0x0, 0xff, 0x0, 0xff },
+ },
+ [CSC_YUV2RGB] = {
+ .type = CSC_YUV2RGB,
+ .matrix = {
+ 0x0254, 0x, 0x0331,
+ 0x0254, 0xff37, 0xfe60,
+ 0x0254, 0x0409, 0x
+ },
+ .pre_bias = { 0xfff0, 0xff80, 0xff80 },
+ .post_bias ={ 0x00, 0x00, 0x00 },
+ .pre_clamp ={ 0x00, 0xff, 0x00, 0xff, 0x00, 0xff },
+ .post_clamp = { 0x00, 0xff, 0x00, 0xff, 0x00, 0xff },
+ },
+ [CSC_RGB2YUV] = {
+ .type = CSC_R
[PATCH 3/4] drm/msm/mdp5: add NV12 support for MDP5
This change adds the NV12 format support for public planes.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 213 +++---
drivers/gpu/drm/msm/msm_fb.c | 2 +-
2 files changed, 194 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 9a57e87..263a16b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -274,6 +274,155 @@ static void set_scanout_locked(struct drm_plane *plane,
plane->fb = fb;
}
+/* Note: mdp5_plane->pipe_lock must be locked */
+static void csc_disable(struct mdp5_kms *mdp5_kms, enum mdp5_pipe pipe)
+{
+ uint32_t value = mdp5_read(mdp5_kms, REG_MDP5_PIPE_OP_MODE(pipe)) &
+~MDP5_PIPE_OP_MODE_CSC_1_EN;
+
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_OP_MODE(pipe), value);
+}
+
+/* Note: mdp5_plane->pipe_lock must be locked */
+static void csc_enable(struct mdp5_kms *mdp5_kms, enum mdp5_pipe pipe,
+ struct csc_cfg *csc)
+{
+ uint32_t i, mode = 0; /* RGB, no CSC */
+ uint32_t *matrix;
+
+ if (unlikely(!csc))
+ return;
+
+ if ((csc->type == CSC_YUV2RGB) || (CSC_YUV2YUV == csc->type))
+ mode |= MDP5_PIPE_OP_MODE_CSC_SRC_DATA_FORMAT(DATA_FORMAT_YUV);
+ if ((csc->type == CSC_RGB2YUV) || (CSC_YUV2YUV == csc->type))
+ mode |= MDP5_PIPE_OP_MODE_CSC_DST_DATA_FORMAT(DATA_FORMAT_YUV);
+ mode |= MDP5_PIPE_OP_MODE_CSC_1_EN;
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_OP_MODE(pipe), mode);
+
+ matrix = csc->matrix;
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_MATRIX_COEFF_0(pipe),
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_0_COEFF_11(matrix[0]) |
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_0_COEFF_12(matrix[1]));
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_MATRIX_COEFF_1(pipe),
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_1_COEFF_13(matrix[2]) |
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_1_COEFF_21(matrix[3]));
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_MATRIX_COEFF_2(pipe),
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_2_COEFF_22(matrix[4]) |
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_2_COEFF_23(matrix[5]));
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_MATRIX_COEFF_3(pipe),
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_3_COEFF_31(matrix[6]) |
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_3_COEFF_32(matrix[7]));
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_MATRIX_COEFF_4(pipe),
+ MDP5_PIPE_CSC_1_MATRIX_COEFF_4_COEFF_33(matrix[8]));
+
+ for (i = 0; i < ARRAY_SIZE(csc->pre_bias); i++) {
+ uint32_t *pre_clamp = csc->pre_clamp;
+ uint32_t *post_clamp = csc->post_clamp;
+
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_PRE_CLAMP(pipe, i),
+ MDP5_PIPE_CSC_1_PRE_CLAMP_REG_HIGH(pre_clamp[2*i+1]) |
+ MDP5_PIPE_CSC_1_PRE_CLAMP_REG_LOW(pre_clamp[2*i]));
+
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_POST_CLAMP(pipe, i),
+ MDP5_PIPE_CSC_1_POST_CLAMP_REG_HIGH(post_clamp[2*i+1]) |
+ MDP5_PIPE_CSC_1_POST_CLAMP_REG_LOW(post_clamp[2*i]));
+
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_PRE_BIAS(pipe, i),
+ MDP5_PIPE_CSC_1_PRE_BIAS_REG_VALUE(csc->pre_bias[i]));
+
+ mdp5_write(mdp5_kms, REG_MDP5_PIPE_CSC_1_POST_BIAS(pipe, i),
+ MDP5_PIPE_CSC_1_POST_BIAS_REG_VALUE(csc->post_bias[i]));
+ }
+}
+
+#define PHASE_STEP_SHIFT 21
+#define DOWN_SCALE_RATIO_MAX 32 /* 2^(26-21) */
+
+static int calc_phase_step(uint32_t src, uint32_t dst, uint32_t *out_phase)
+{
+ uint32_t unit;
+
+ if (src == 0 || dst == 0)
+ return -EINVAL;
+
+ /*
+* PHASE_STEP_X/Y is coded on 26 bits (25:0),
+* where 2^21 represents the unity "1" in fixed-point hardware design.
+* This leaves 5 bits for the integer part (downscale case):
+* -> maximum downscale ratio = 0b1_ = 31
+*/
+ if (src > (dst * DOWN_SCALE_RATIO_MAX))
+ return -EOVERFLOW;
+
+ unit = 1 << PHASE_STEP_SHIFT;
+ *out_phase = mult_frac(unit, src, dst);
+
+ return 0;
+}
+
+static int calc_scalex_steps(uint32_t pixel_format, uint32_t src, uint32_t
dest,
+ uint32_t phasex_steps[2])
+{
+ uint32_t phasex_step;
+ unsigned int hsub;
+ int ret;
+
+ ret = calc_phase_step(src, dest, &phasex_step);
+ if (ret)
+ return ret;
+
+ hsub = drm_format_horz_chroma_subsampling(pixel_format);
+
+ phasex_steps[0] = phasex_step;
+ phasex_steps[1] = phasex_step / hsub;
+
+ return 0;
+}
+
+static int calc_scaley_steps(uint32_t pixel_format, uint32_t src, uin
[PATCH 4/4] drm/msm/mdp4: add YUV format support
From: Beeresh Gopal
The patch add support for YUV frame format
for MDP4 platform.
Signed-off-by: Beeresh Gopal
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 104 +++---
1 file changed, 95 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
index 76d0a40..6e3c1ef 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
@@ -17,6 +17,8 @@
#include "mdp4_kms.h"
+#define DOWN_SCALE_MAX 8
+#define UP_SCALE_MAX 8
struct mdp4_plane {
struct drm_plane base;
@@ -135,10 +137,6 @@ static void mdp4_plane_set_scanout(struct drm_plane *plane,
struct mdp4_plane *mdp4_plane = to_mdp4_plane(plane);
struct mdp4_kms *mdp4_kms = get_kms(plane);
enum mdp4_pipe pipe = mdp4_plane->pipe;
- uint32_t iova = msm_framebuffer_iova(fb, mdp4_kms->id, 0);
-
- DBG("%s: set_scanout: %08x (%u)", mdp4_plane->name,
- iova, fb->pitches[0]);
mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_STRIDE_A(pipe),
MDP4_PIPE_SRC_STRIDE_A_P0(fb->pitches[0]) |
@@ -148,11 +146,45 @@ static void mdp4_plane_set_scanout(struct drm_plane
*plane,
MDP4_PIPE_SRC_STRIDE_B_P2(fb->pitches[2]) |
MDP4_PIPE_SRC_STRIDE_B_P3(fb->pitches[3]));
- mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRCP0_BASE(pipe), iova);
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRCP0_BASE(pipe),
+ msm_framebuffer_iova(fb, mdp4_kms->id, 0));
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRCP1_BASE(pipe),
+ msm_framebuffer_iova(fb, mdp4_kms->id, 1));
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRCP2_BASE(pipe),
+ msm_framebuffer_iova(fb, mdp4_kms->id, 2));
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRCP3_BASE(pipe),
+ msm_framebuffer_iova(fb, mdp4_kms->id, 3));
plane->fb = fb;
}
+static void mdp4_write_csc_config(struct mdp4_kms *mdp4_kms,
+ enum mdp4_pipe pipe, struct csc_cfg *csc)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(csc->matrix); i++) {
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_CSC_MV(pipe, i),
+ csc->matrix[i]);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(csc->post_bias) ; i++) {
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_CSC_PRE_BV(pipe, i),
+ csc->pre_bias[i]);
+
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_CSC_POST_BV(pipe, i),
+ csc->post_bias[i]);
+ }
+
+ for (i = 0; i < ARRAY_SIZE(csc->post_clamp) ; i++) {
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_CSC_PRE_LV(pipe, i),
+ csc->pre_clamp[i]);
+
+ mdp4_write(mdp4_kms, REG_MDP4_PIPE_CSC_POST_LV(pipe, i),
+ csc->post_clamp[i]);
+ }
+}
+
#define MDP4_VG_PHASE_STEP_DEFAULT 0x2000
static int mdp4_plane_mode_set(struct drm_plane *plane,
@@ -162,6 +194,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h)
{
+ struct drm_device *dev = plane->dev;
struct mdp4_plane *mdp4_plane = to_mdp4_plane(plane);
struct mdp4_kms *mdp4_kms = get_kms(plane);
enum mdp4_pipe pipe = mdp4_plane->pipe;
@@ -185,14 +218,59 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
fb->base.id, src_x, src_y, src_w, src_h,
crtc->base.id, crtc_x, crtc_y, crtc_w, crtc_h);
+ format = to_mdp_format(msm_framebuffer_format(fb));
+
+ if (src_w > (crtc_w * DOWN_SCALE_MAX)) {
+ dev_err(dev->dev, "Width down scaling exceeds limits!\n");
+ return -ERANGE;
+ }
+
+ if (src_h > (crtc_h * DOWN_SCALE_MAX)) {
+ dev_err(dev->dev, "Height down scaling exceeds limits!\n");
+ return -ERANGE;
+ }
+
+ if (crtc_w > (src_w * UP_SCALE_MAX)) {
+ dev_err(dev->dev, "Width up scaling exceeds limits!\n");
+ return -ERANGE;
+ }
+
+ if (crtc_h > (src_h * UP_SCALE_MAX)) {
+ dev_err(dev->dev, "Height up scaling exceeds limits!\n");
+ return -ERANGE;
+ }
+
if (src_w != crtc_w) {
+ uint32_t sel_unit = SCALE_FIR;
op_mode |= MDP4_PIPE_OP_MODE_SCALEX_EN;
- /* TODO calc phasex_step */
+
+ if (MDP_FORMAT_IS_YUV(format)) {
+ if (crtc_w > src_w)
+ sel_unit = SCALE_PIXEL_RPT;
+ else if (crtc_w <= (src_w / 4))
+ sel_unit = SCALE_MN_PHASE;
+
+ op_mode |= MDP4_PIPE_OP_MODE_SCALEX_UNIT_SEL(sel_unit);
+
[Bug 73378] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks!
https://bugs.freedesktop.org/show_bug.cgi?id=73378 --- Comment #12 from equeim at gmail.com --- Same on 3.18.0 -- 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/20141208/1d0bd794/attachment.html>
[Bug 88911] Radeon: Patch "drm/radeon: fix speaker allocation setup" causes kernel lockup
https://bugzilla.kernel.org/show_bug.cgi?id=88911 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 4/6] drm/radeon: add explicit command submission sync
From: Christian König
The driver falls back to explicit synchronization as soon as
buffers move between clients or are moved by TTM.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_cs.c | 24 +++-
include/uapi/drm/radeon_drm.h | 7 ---
3 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b9fde1d..1529afb 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1101,6 +1101,7 @@ struct radeon_cs_parser {
struct radeon_cs_chunk *chunk_relocs;
struct radeon_cs_chunk *chunk_flags;
struct radeon_cs_chunk *chunk_const_ib;
+ struct radeon_cs_chunk *chunk_wait_for;
struct radeon_ibib;
struct radeon_ibconst_ib;
void*track;
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index c0fc8d8..a73f9da 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -165,7 +165,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
}
p->relocs[i].tv.bo = &p->relocs[i].robj->tbo;
- p->relocs[i].tv.shared = !r->write_domain;
+ p->relocs[i].tv.shared = !r->write_domain ||
+!!p->chunk_wait_for;
radeon_cs_buckets_add(&buckets, &p->relocs[i].tv.head,
priority);
@@ -235,6 +236,23 @@ static int radeon_cs_sync_rings(struct radeon_cs_parser *p)
struct radeon_bo_list *reloc;
int r;
+ if (p->chunk_wait_for) {
+ struct radeon_fpriv *fpriv = p->filp->driver_priv;
+ unsigned i;
+
+ for (i = 0; i < p->chunk_wait_for->length_dw; i += 2) {
+ struct radeon_fence *fence;
+ uint64_t *id;
+
+ id = (uint64_t *)&p->chunk_wait_for->kdata[i];
+
+ mutex_lock(&fpriv->seq_lock);
+ fence = radeon_seq_query(fpriv->seq, *id);
+ radeon_sync_fence(&p->ib.sync, fence);
+ mutex_unlock(&fpriv->seq_lock);
+ }
+ }
+
list_for_each_entry(reloc, &p->validated, tv.head) {
struct reservation_object *resv;
long owner = reloc->tv.shared ? (long)p->filp :
@@ -317,6 +335,10 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
if (p->chunks[i].length_dw == 0)
return -EINVAL;
}
+ if (user_chunk.chunk_id == RADEON_CHUNK_ID_WAIT_FOR) {
+ p->chunk_wait_for = &p->chunks[i];
+ /* zero length wait for list is actually useful */
+ }
size = p->chunks[i].length_dw;
cdata = (void __user *)(unsigned long)user_chunk.chunk_data;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 6b2b2e7..a34e3db 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -942,10 +942,11 @@ struct drm_radeon_gem_va {
uint64_toffset;
};
-#define RADEON_CHUNK_ID_RELOCS 0x01
-#define RADEON_CHUNK_ID_IB 0x02
-#define RADEON_CHUNK_ID_FLAGS 0x03
+#define RADEON_CHUNK_ID_RELOCS 0x01
+#define RADEON_CHUNK_ID_IB 0x02
+#define RADEON_CHUNK_ID_FLAGS 0x03
#define RADEON_CHUNK_ID_CONST_IB 0x04
+#define RADEON_CHUNK_ID_WAIT_FOR 0x05
/* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags: */
#define RADEON_CS_KEEP_TILING_FLAGS 0x01
--
1.9.1
[PATCH 1/6] drm/radeon: take a fence reference in the sync code
From: Christian König
Just to be sure that fences we sync to won't be released while accessed.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_sync.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_sync.c
b/drivers/gpu/drm/radeon/radeon_sync.c
index 02ac8a1..6fccaaf 100644
--- a/drivers/gpu/drm/radeon/radeon_sync.c
+++ b/drivers/gpu/drm/radeon/radeon_sync.c
@@ -69,11 +69,15 @@ void radeon_sync_fence(struct radeon_sync *sync,
return;
other = sync->sync_to[fence->ring];
- sync->sync_to[fence->ring] = radeon_fence_later(fence, other);
+ sync->sync_to[fence->ring] = radeon_fence_ref(
+ radeon_fence_later(fence, other));
+ radeon_fence_unref(&other);
if (fence->is_vm_update) {
other = sync->last_vm_update;
- sync->last_vm_update = radeon_fence_later(fence, other);
+ sync->last_vm_update = radeon_fence_ref(
+ radeon_fence_later(fence, other));
+ radeon_fence_unref(&other);
}
}
@@ -217,4 +221,9 @@ void radeon_sync_free(struct radeon_device *rdev,
for (i = 0; i < RADEON_NUM_SYNCS; ++i)
radeon_semaphore_free(rdev, &sync->semaphores[i], fence);
+
+ for (i = 0; i < RADEON_NUM_RINGS; ++i)
+ radeon_fence_unref(&sync->sync_to[i]);
+
+ radeon_fence_unref(&sync->last_vm_update);
}
--
1.9.1
[PATCH 5/6] drm/radeon: optionally return an ID for the last PT update
From: Christian König
PT updates can be seen as command submissions as well,
and we don't necessary need to wait on all of them.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_gem.c | 12 +++-
include/uapi/drm/radeon_drm.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index fe48f22..dd45611 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -691,8 +691,18 @@ int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
default:
break;
}
- if (!r)
+ args->id = 0;
+ if (!r) {
+ struct radeon_fence *fence;
+
radeon_gem_va_update_vm(rdev, bo_va);
+ fence = bo_va->last_pt_update;
+ if (fence) {
+ mutex_lock(&fpriv->seq_lock);
+ args->id = radeon_seq_push(&fpriv->seq, fence);
+ mutex_unlock(&fpriv->seq_lock);
+ }
+ }
args->operation = RADEON_VA_RESULT_OK;
if (r) {
args->operation = RADEON_VA_RESULT_ERROR;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index a34e3db..2c50838 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -940,6 +940,7 @@ struct drm_radeon_gem_va {
uint32_tvm_id;
uint32_tflags;
uint64_toffset;
+ uint64_tid;
};
#define RADEON_CHUNK_ID_RELOCS 0x01
--
1.9.1
[PATCH 3/6] drm/radeon: add command submission IDs
From: Christian König
This patch adds a new 64bit ID as a result to each command submission.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/radeon.h | 13 +-
drivers/gpu/drm/radeon/radeon_cs.c | 13 ++
drivers/gpu/drm/radeon/radeon_kms.c | 41 +++
drivers/gpu/drm/radeon/radeon_seq.c | 229
include/uapi/drm/radeon_drm.h | 1 +
6 files changed, 277 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/radeon_seq.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 12bc212..7145f15 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -81,7 +81,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_ib.o radeon_mn.o
\
- radeon_sync.o
+ radeon_sync.o radeon_seq.o
# add async DMA block
radeon-y += \
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 3968f91..b9fde1d 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -433,6 +433,15 @@ static inline bool radeon_fence_is_earlier(struct
radeon_fence *a,
}
/*
+ * Userspace command submission identifier generation
+ */
+struct radeon_seq;
+
+uint64_t radeon_seq_push(struct radeon_seq **seq, struct radeon_fence *fence);
+struct radeon_fence *radeon_seq_query(struct radeon_seq *seq, uint64_t id);
+void radeon_seq_destroy(struct radeon_seq **seq);
+
+/*
* Tiling registers
*/
struct radeon_surface_reg {
@@ -975,7 +984,9 @@ struct radeon_vm_manager {
* file private structure
*/
struct radeon_fpriv {
- struct radeon_vmvm;
+ struct radeon_vmvm;
+ struct mutexseq_lock;
+ struct radeon_seq *seq;
};
/*
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 3c3b7d9..c0fc8d8 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -398,6 +398,19 @@ static void radeon_cs_parser_fini(struct radeon_cs_parser
*parser, int error, bo
unsigned i;
if (!error) {
+ if (parser->chunk_flags &&
+ parser->chunk_flags->length_dw > 4) {
+ struct radeon_fpriv *fpriv = parser->filp->driver_priv;
+ uint32_t __user *to = parser->chunk_flags->user_ptr;
+ uint64_t id;
+
+ mutex_lock(&fpriv->seq_lock);
+ id = radeon_seq_push(&fpriv->seq, parser->ib.fence);
+ mutex_unlock(&fpriv->seq_lock);
+
+ copy_to_user(&to[3], &id, sizeof(uint64_t));
+ }
+
/* Sort the buffer list from the smallest to largest buffer,
* which affects the order of buffers in the LRU list.
* This assures that the smallest buffers are added first
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index f4dd26a..db5c986 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -585,39 +585,34 @@ void radeon_driver_lastclose_kms(struct drm_device *dev)
*/
int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv)
{
+ struct radeon_fpriv *fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
struct radeon_device *rdev = dev->dev_private;
int r;
- file_priv->driver_priv = NULL;
+ if (unlikely(!fpriv))
+ return -ENOMEM;
+
+ file_priv->driver_priv = fpriv;
r = pm_runtime_get_sync(dev->dev);
if (r < 0)
- return r;
+ goto error;
/* new gpu have virtual address space support */
if (rdev->family >= CHIP_CAYMAN) {
- struct radeon_fpriv *fpriv;
struct radeon_vm *vm;
int r;
- fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
- if (unlikely(!fpriv)) {
- return -ENOMEM;
- }
-
vm = &fpriv->vm;
r = radeon_vm_init(rdev, vm);
- if (r) {
- kfree(fpriv);
- return r;
- }
+ if (r)
+ goto error;
if (rdev->accel_working) {
r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false);
if (r) {
radeon_vm_fini(rdev, vm);
- kfree(fpriv);
- return r;
+ goto error;
}
/* map
[PATCH 2/6] drm/radeon: add fence owners
From: Christian König
This way we can track who created the fence and then only wait
on fences that userspace doesn't knows about.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c | 8 +---
drivers/gpu/drm/radeon/cik_sdma.c | 8 +---
drivers/gpu/drm/radeon/evergreen_dma.c | 5 +++--
drivers/gpu/drm/radeon/r100.c | 6 --
drivers/gpu/drm/radeon/r200.c | 3 ++-
drivers/gpu/drm/radeon/r600.c | 8 +---
drivers/gpu/drm/radeon/r600_dma.c | 8 +---
drivers/gpu/drm/radeon/radeon.h| 15 +++
drivers/gpu/drm/radeon/radeon_cs.c | 14 +-
drivers/gpu/drm/radeon/radeon_fence.c | 4 ++--
drivers/gpu/drm/radeon/radeon_ib.c | 5 +++--
drivers/gpu/drm/radeon/radeon_sync.c | 19 +++
drivers/gpu/drm/radeon/radeon_test.c | 3 ++-
drivers/gpu/drm/radeon/radeon_uvd.c| 3 ++-
drivers/gpu/drm/radeon/radeon_vce.c| 6 --
drivers/gpu/drm/radeon/radeon_vm.c | 18 ++
drivers/gpu/drm/radeon/rv770_dma.c | 5 +++--
drivers/gpu/drm/radeon/si_dma.c| 5 +++--
18 files changed, 89 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 6dcde37..7f15ec5 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -4013,7 +4013,7 @@ struct radeon_fence *cik_copy_cpdma(struct radeon_device
*rdev,
return ERR_PTR(r);
}
- radeon_sync_resv(rdev, &sync, resv, false);
+ radeon_sync_resv(rdev, &sync, resv, RADEON_FENCE_OWNER_UNDEFINED);
radeon_sync_rings(rdev, &sync, ring->idx);
for (i = 0; i < num_loops; i++) {
@@ -4035,7 +4035,8 @@ struct radeon_fence *cik_copy_cpdma(struct radeon_device
*rdev,
dst_offset += cur_size_in_bytes;
}
- r = radeon_fence_emit(rdev, &fence, ring->idx);
+ r = radeon_fence_emit(rdev, &fence, ring->idx,
+ RADEON_FENCE_OWNER_MOVE);
if (r) {
radeon_ring_unlock_undo(rdev, ring);
radeon_sync_free(rdev, &sync, NULL);
@@ -4141,7 +4142,8 @@ int cik_ib_test(struct radeon_device *rdev, struct
radeon_ring *ring)
ib.ptr[1] = ((scratch - PACKET3_SET_UCONFIG_REG_START) >> 2);
ib.ptr[2] = 0xDEADBEEF;
ib.length_dw = 3;
- r = radeon_ib_schedule(rdev, &ib, NULL, false);
+ r = radeon_ib_schedule(rdev, &ib, NULL, false,
+ RADEON_FENCE_OWNER_UNDEFINED);
if (r) {
radeon_scratch_free(rdev, scratch);
radeon_ib_free(rdev, &ib);
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c
b/drivers/gpu/drm/radeon/cik_sdma.c
index dde5c7e..2261a88 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -560,7 +560,7 @@ struct radeon_fence *cik_copy_dma(struct radeon_device
*rdev,
return ERR_PTR(r);
}
- radeon_sync_resv(rdev, &sync, resv, false);
+ radeon_sync_resv(rdev, &sync, resv, RADEON_FENCE_OWNER_UNDEFINED);
radeon_sync_rings(rdev, &sync, ring->idx);
for (i = 0; i < num_loops; i++) {
@@ -579,7 +579,8 @@ struct radeon_fence *cik_copy_dma(struct radeon_device
*rdev,
dst_offset += cur_size_in_bytes;
}
- r = radeon_fence_emit(rdev, &fence, ring->idx);
+ r = radeon_fence_emit(rdev, &fence, ring->idx,
+ RADEON_FENCE_OWNER_MOVE);
if (r) {
radeon_ring_unlock_undo(rdev, ring);
radeon_sync_free(rdev, &sync, NULL);
@@ -691,7 +692,8 @@ int cik_sdma_ib_test(struct radeon_device *rdev, struct
radeon_ring *ring)
ib.ptr[4] = 0xDEADBEEF;
ib.length_dw = 5;
- r = radeon_ib_schedule(rdev, &ib, NULL, false);
+ r = radeon_ib_schedule(rdev, &ib, NULL, false,
+ RADEON_FENCE_OWNER_UNDEFINED);
if (r) {
radeon_ib_free(rdev, &ib);
DRM_ERROR("radeon: failed to schedule ib (%d).\n", r);
diff --git a/drivers/gpu/drm/radeon/evergreen_dma.c
b/drivers/gpu/drm/radeon/evergreen_dma.c
index 96535aa..094df95 100644
--- a/drivers/gpu/drm/radeon/evergreen_dma.c
+++ b/drivers/gpu/drm/radeon/evergreen_dma.c
@@ -129,7 +129,7 @@ struct radeon_fence *evergreen_copy_dma(struct
radeon_device *rdev,
return ERR_PTR(r);
}
- radeon_sync_resv(rdev, &sync, resv, false);
+ radeon_sync_resv(rdev, &sync, resv, RADEON_FENCE_OWNER_UNDEFINED);
radeon_sync_rings(rdev, &sync, ring->idx);
for (i = 0; i < num_loops; i++) {
@@ -146,7 +146,8 @@ struct radeon_fence *evergreen_copy_dma(struct
radeon_device *rdev,
dst_offset += cur_size_in_dw * 4;
}
- r = radeon_fence_emit(rdev, &fence, ring->idx);
+ r = radeon_fence_emit(rdev, &fence, ring->idx,
+ RADEON_FENCE_OWNER_MOVE);
i
[PATCH 6/6] drm/radeon: add IOCTL to wait for a specific CS
From: Christian König
At least inside the same client we should stop waiting for a buffer to be
idle, but rather wait for a specific command submission to complete.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 2 ++
drivers/gpu/drm/radeon/radeon_gem.c | 26 ++
drivers/gpu/drm/radeon/radeon_kms.c | 1 +
include/uapi/drm/radeon_drm.h | 7 +++
4 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 1529afb..d8bf3a7 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2230,6 +2230,8 @@ int radeon_gem_busy_ioctl(struct drm_device *dev, void
*data,
struct drm_file *filp);
int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int radeon_gem_wait_cs_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
int radeon_gem_va_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
int radeon_gem_op_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index dd45611..297f327 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -494,6 +494,32 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
void *data,
return r;
}
+int radeon_gem_wait_cs_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp)
+{
+ struct radeon_fpriv *fpriv = filp->driver_priv;
+ struct drm_radeon_gem_wait_cs *args = data;
+ struct radeon_fence *fence;
+ unsigned long timeout;
+ long r;
+
+ mutex_lock(&fpriv->seq_lock);
+ fence = radeon_fence_ref(radeon_seq_query(fpriv->seq, args->id));
+ mutex_unlock(&fpriv->seq_lock);
+
+ timeout = nsecs_to_jiffies(args->timeout);
+ r = fence_wait_timeout(&fence->base, true, timeout);
+ radeon_fence_unref(&fence);
+
+ if (r == 0)
+ return -EBUSY;
+
+ if (r < 0)
+ return r;
+
+ return 0;
+}
+
int radeon_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp)
{
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index db5c986..69b74a8 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -892,5 +892,6 @@ const struct drm_ioctl_desc radeon_ioctls_kms[] = {
DRM_IOCTL_DEF_DRV(RADEON_GEM_VA, radeon_gem_va_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_OP, radeon_gem_op_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(RADEON_GEM_USERPTR, radeon_gem_userptr_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(RADEON_GEM_WAIT_CS, radeon_gem_wait_cs_ioctl,
DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
int radeon_max_kms_ioctl = ARRAY_SIZE(radeon_ioctls_kms);
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 2c50838..d700c06 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -512,6 +512,7 @@ typedef struct {
#define DRM_RADEON_GEM_VA 0x2b
#define DRM_RADEON_GEM_OP 0x2c
#define DRM_RADEON_GEM_USERPTR 0x2d
+#define DRM_RADEON_GEM_WAIT_CS 0x2e
#define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE +
DRM_RADEON_CP_INIT, drm_radeon_init_t)
#define DRM_IOCTL_RADEON_CP_START DRM_IO( DRM_COMMAND_BASE +
DRM_RADEON_CP_START)
@@ -556,6 +557,7 @@ typedef struct {
#define DRM_IOCTL_RADEON_GEM_VADRM_IOWR(DRM_COMMAND_BASE +
DRM_RADEON_GEM_VA, struct drm_radeon_gem_va)
#define DRM_IOCTL_RADEON_GEM_OPDRM_IOWR(DRM_COMMAND_BASE +
DRM_RADEON_GEM_OP, struct drm_radeon_gem_op)
#define DRM_IOCTL_RADEON_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
DRM_RADEON_GEM_USERPTR, struct drm_radeon_gem_userptr)
+#define DRM_IOCTL_RADEON_GEM_WAIT_CS DRM_IOWR(DRM_COMMAND_BASE +
DRM_RADEON_GEM_WAIT_CS, struct drm_radeon_gem_wait_cs)
typedef struct drm_radeon_init {
enum {
@@ -880,6 +882,11 @@ struct drm_radeon_gem_wait_idle {
uint32_tpad;
};
+struct drm_radeon_gem_wait_cs {
+ uint64_tid;
+ uint64_ttimeout;
+};
+
struct drm_radeon_gem_busy {
uint32_thandle;
uint32_tdomain;
--
1.9.1
[Intel-gfx] [PATCH] gpu: drm: i915: intel_display.c: Remove unused function
2014-12-08 12:17 GMT-02:00 Daniel Vetter : > On Mon, Dec 08, 2014 at 10:32:49AM -0200, Paulo Zanoni wrote: >> 2014-12-08 6:42 GMT-02:00 Daniel Vetter : >> > On Sun, Dec 07, 2014 at 07:29:17PM +0100, Rickard Strandqvist wrote: >> >> Remove the function intel_output_name() that is not used anywhere. >> >> >> >> This was partially found by using a static code analysis program called >> >> cppcheck. >> >> >> >> Signed-off-by: Rickard Strandqvist > >> spectrumdigital.se> >> > >> > Queued for 3.20, thanks for the patch. >> >> This function was created for the "DDI personality" patches. We merged >> the function but never ended up merging the patch containing the >> callers... > > Oops, I've thought this is a renmant from the very first days of kms that > somehow stuck around. That's what I get for once not using git blame > excessively :( Want me to drop the patch again? I am not opposed to the removal of an unused function: I understand the value in the removal, and I also understand the reasons to keep it. I was just pointing the reason of why we got here: we merged patch 1/2 but ended up never merging patch 2/2 because we always spot some additional work required and it's a very low priority bug. If this function is removed, the next person to try to ressurrect the ddi personality patch can quickly resurrect it or even write a new implementation from scratch. It is your decision :) > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni
[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend
https://bugs.freedesktop.org/show_bug.cgi?id=84232 --- Comment #15 from Tom Stellard --- (In reply to Vitaliy Filippov from comment #14) > Wow!! Tom, did you just fix this bug with commit > 857550322c6fe679d17d35c885606ae1d8cf43b6? Possibly, does blender work now (or at least does it no longer crash)? -- 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/20141208/e2c7980f/attachment.html>
[PATCH 0/4] removal of extra abstraction layers
Hi Inki, 2014-12-06 Dave Airlie : > On 2 December 2014 at 22:38, Gustavo Padovan wrote: > > Hi Inki, > > > > Can you please review this? I also have sent other two patch sets that sits > > on > > top of this one. Thanks. > > Inki, any plans on when you can get to looking at this? > > I think cleaning up exynos so we can get atomic using it is something > that will benefit it heavily. Besides these patches I have other two clean up patchsets[0][1] that are very important for atomic support, can you review these two too? [0] http://www.spinics.net/lists/linux-samsung-soc/msg39614.html [1] http://www.spinics.net/lists/linux-samsung-soc/msg39632.html Gustavo
[PATCH 1/2] drm/msm: Initial add eDP support in msm drm driver (V2)
On Mon, Dec 8, 2014 at 8:28 AM, Thierry Reding
wrote:
> On Fri, Dec 05, 2014 at 04:30:00PM -0500, Hai Li wrote:
> [...]
>
>> + if (IS_ERR(edp))
>> + return PTR_ERR(edp);
>> + priv->edp = edp;
>> +
>> + return 0;
>> +}
>> +
>> +static void edp_unbind(struct device *dev, struct device *master,
>> + void *data)
>
> We typically align parameters on subsequent lines with the first
> parameter on the first line. But perhaps Rob doesn't care so much.
no, I don't.. and aligned params is kinda annoying if function name or
return type changes make it get out of alignment ;-)
but either way is fine
[snip]
>> +/* Second part of initialization, the drm/kms level modeset_init */
>> +int msm_edp_modeset_init(struct msm_edp *edp,
>> + struct drm_device *dev, struct drm_encoder *encoder)
>> +{
>> + struct platform_device *pdev = edp->pdev;
>> + struct msm_drm_private *priv = dev->dev_private;
>> + int ret;
>> +
>> + edp->encoder = encoder;
>> + edp->dev = dev;
>> +
>> + edp->bridge = msm_edp_bridge_init(edp);
>> + if (IS_ERR(edp->bridge)) {
>> + ret = PTR_ERR(edp->bridge);
>> + dev_err(dev->dev, "failed to create eDP bridge: %d\n", ret);
>> + edp->bridge = NULL;
>> + goto fail;
>> + }
>> +
>> + edp->connector = msm_edp_connector_init(edp);
>> + if (IS_ERR(edp->connector)) {
>> + ret = PTR_ERR(edp->connector);
>> + dev_err(dev->dev, "failed to create eDP connector: %d\n", ret);
>> + edp->connector = NULL;
>> + goto fail;
>> + }
>> +
>> + edp->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
>
> Why not use the more idiomatic platform_get_irq()?
It may have been a quirk of the downstream 3.10 kernel that I also
have to deal with for some devices, but I couldn't get
platform_get_irq() to work and so used irq_of_parse_and_map() in the
hdmi code. I assume eDP would have the identical problem.
>> + if (edp->irq < 0) {
>> + ret = edp->irq;
>> + dev_err(dev->dev, "failed to get irq: %d\n", ret);
>
> s/irq/IRQ/
>
>> diff --git a/drivers/gpu/drm/msm/edp/edp.h b/drivers/gpu/drm/msm/edp/edp.h
> [...]
>> +#ifndef __EDP_CONNECTOR_H__
>> +#define __EDP_CONNECTOR_H__
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> These should be alphabetically sorted.
>
>> diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c
>> b/drivers/gpu/drm/msm/edp/edp_aux.c
> [...]
>> +#define to_edp_aux(x) container_of(x, struct edp_aux, drm_aux)
>
> Perhaps this should be a static inline function for better type safety.
>
#define is at least consistent w/ rest of drm/msm code (and
obj_to_xyz() in drm core).. although if misused it probably gives a
more confusing compile error compared to static inline fxn.
I wouldn't reject a patch that converted them all to static inline
fxns, but I think this is ok as-is
[snip]
>
>> +static int edp_sink_power_state(struct edp_ctrl *ctrl, u8 state)
>> +{
>> + u8 s = state;
>> +
>> + DBG("%d", s);
>> +
>> + if (ctrl->dp_link.revision < 0x11)
>> + return 0;
>> +
>> + if (drm_dp_dpcd_write(ctrl->drm_aux, DP_SET_POWER, &s, 1) < 1) {
>> + pr_err("%s: Set power state to panel failed\n", __func__);
>> + return -ENOLINK;
>> + }
>> +
>> + return 0;
>> +}
>
> This is essentially drm_dp_link_power_up()/drm_dp_link_power_down().
> Please use common code where available. And if it's not available yet
> the code is completely generic, please add a core function so that
> other drivers can reuse it.
jfyi, I already have a patch that rips this back out and uses core
functions, once drm_dp_link_power_down() is merged ;-)
[snip]
>> +irqreturn_t msm_edp_ctrl_irq(struct edp_ctrl *ctrl)
>> +{
> [...]
>> + if (isr1 & EDP_INTERRUPT_REG_1_HPD)
>> + DBG("edp_hpd");
>
> Don't you want to handle this?
>
>> +
>> + if (isr2 & EDP_INTERRUPT_REG_2_READY_FOR_VIDEO)
>> + DBG("edp_video_ready");
>> +
>> + if (isr2 & EDP_INTERRUPT_REG_2_IDLE_PATTERNs_SENT) {
>
> s/PATTERNs/PATTERNS/? I was going to make that comment to the definition
> of this define, but I can't seem to find it. I suspect that it comes
> from one of the generated headers, but I can't seem to find either the
> generated header nor the XML.
yes, it is generated..
fyi: https://github.com/freedreno/envytools/tree/master/rnndb
>
>> + DBG("idle_patterns_sent");
>> + complete(&ctrl->idle_comp);
>> + }
>> +
>> + msm_edp_aux_irq(ctrl->aux, isr1);
>> +
>> + return IRQ_HANDLED;
>> +}
> [...]
>> +bool msm_edp_ctrl_panel_connected(struct edp_ctrl *ctrl)
>> +{
>> + bool ret;
>
> This is unnecessary, the only place where this is used is to return the
> value of ctrl->edp_connected. You can use that directly instead.
>
> [...]
>> + ret = ctrl->edp_connected;
>> + mutex_unlock(&ctrl->dev_mutex);
[Bug 87059] Graphical glitches r9290
https://bugs.freedesktop.org/show_bug.cgi?id=87059 --- Comment #5 from smoki --- (In reply to Jarkko K from comment #3) > > [Properties] > "opengl.version"="3.0 Mesa 10.5.0-devel (git-d8da6de 2014-12-06 > trusty-oibaf-ppa)" That ppa still use llvm-3.5, OK. Yes i manage to reporuduce it now with llvm-3.5 and with GFX Quality high setted in game, but with low issue is not there. Anyway issue as i see is mostly fixed if current mesa is compiled against llvm-3.6 svn. I don't use ubuntu but you might want to try some ppas which does that like this one - not day to day up to date, but hopefully should work at least for you to check if this issue still appear there for you? https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa -- 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/20141208/01fe4f56/attachment-0001.html>
[PATCH] drm/atomic: fix potential null ptr on plane enable
On Mon, Dec 8, 2014 at 7:45 AM, Rob Clark wrote:
>
> When a plane is being enabled, plane->crtc has not been set yet. Use
> plane->state->crtc.
>
Reviewed-by: Sean Paul
>
> Signed-off-by: Rob Clark
> ---
> Looks like this is still missing on drm-next.. I probably forgot to
> send it earlier.
>
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 4a78a77..bbdbe47 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -61,7 +61,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state
> *state,
> struct drm_crtc_state *crtc_state;
>
> if (plane->state->crtc) {
> - crtc_state = state->crtc_states[drm_crtc_index(plane->crtc)];
> + crtc_state =
> state->crtc_states[drm_crtc_index(plane->state->crtc)];
>
> if (WARN_ON(!crtc_state))
> return;
> --
> 1.9.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87059] Graphical glitches r9290
https://bugs.freedesktop.org/show_bug.cgi?id=87059 --- Comment #6 from Jarkko K --- I am not so keen on changing ppa, but I tried the graphic quality. I changed it from high to low and the boxes are gone. Any idea what causes this? -- 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/20141208/c7a36cf1/attachment.html>
[Bug 87059] Graphical glitches r9290
https://bugs.freedesktop.org/show_bug.cgi?id=87059 --- Comment #7 from smoki --- (In reply to Jarkko K from comment #6) > > Any idea what causes this? Not sure probably what happens in some other games like in bug 86038 , major blackiness which came from lighting seems to gone using llvm-3.6 there too, but still not completely even if you use llvm-3.6, most likely this comment goes to the right track: https://bugs.freedesktop.org/show_bug.cgi?id=83510#c8 It is discussed on mesa ml, so hopefully it will get fixed soon :) http://lists.freedesktop.org/archives/mesa-dev/2014-December/071973.html -- 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/20141208/040f359f/attachment.html>
[PATCH] drm/atomic: fix potential null ptr on plane enable
On Mon, Dec 08, 2014 at 11:42:56AM -0800, Sean Paul wrote: > On Mon, Dec 8, 2014 at 7:45 AM, Rob Clark wrote: > > > > When a plane is being enabled, plane->crtc has not been set yet. Use > > plane->state->crtc. > > > > Reviewed-by: Sean Paul Merged to topic/atomic-core, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
nouveau: Do you really want these new links in the kernel tree?
/usr/src/linux-3.18> find drivers/ -type l | xargs ls -al lrwxrwxrwx 1 markh users 21 Dec 7 17:21 ./drivers/gpu/drm/nouveau/core/include/nvif/class.h -> ../../../nvif/class.h lrwxrwxrwx 1 markh users 21 Dec 7 17:21 ./drivers/gpu/drm/nouveau/core/include/nvif/event.h -> ../../../nvif/event.h lrwxrwxrwx 1 markh users 21 Dec 7 17:21 ./drivers/gpu/drm/nouveau/core/include/nvif/ioctl.h -> ../../../nvif/ioctl.h lrwxrwxrwx 1 markh users 22 Dec 7 17:21 ./drivers/gpu/drm/nouveau/core/include/nvif/unpack.h -> ../../../nvif/unpack.h lrwxrwxrwx 1 markh users 12 Dec 7 17:21 ./drivers/gpu/drm/nouveau/nvif/os.h -> ../core/os.h Regards Mark
[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend
https://bugs.freedesktop.org/show_bug.cgi?id=84232 --- Comment #16 from Vitaliy Filippov --- (In reply to Tom Stellard from comment #15) > Possibly, does blender work now (or at least does it no longer crash)? Yes, it doesn't crash anymore, thanks! There are still other bugs that prevent it from running, and as I understand most renderer features are disabled with default flags/defines under Mesa... >From https://developer.blender.org/T41912 - "Note though: Building without SVM gives you only very basic clay like rendering, not really usable." The first bug is about libclc - it incorrectly references fabsf() in R600 bytecode files, while it should probably use llvm.fabs.f32()... Where to report it? Second, it seems Blender developers are using half-precision floats (vstore_half4 function)... it's used in only one place and I don't know if its usage is really critical, but it of course prevents the kernel from compiling... I've reported it here https://developer.blender.org/T42813 -- 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/20141208/842505a8/attachment.html>
[PATCH] Add new DRM_MODE_CONNECTOR and _ENCODER defines
Update drm_mode.h defines from kernel upstream for connector and
encoder types to expose DSI and other newly defined types.
Signed-off-by: Adam Cheney mailto:acheney at nvidia.com>>
---
include/drm/drm_mode.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 76fd76b..263cf07 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -173,6 +173,9 @@ struct drm_mode_get_plane_res {
#define DRM_MODE_ENCODER_TMDS 2
#define DRM_MODE_ENCODER_LVDS3
#define DRM_MODE_ENCODER_TVDAC 4
+#define DRM_MODE_ENCODER_VIRTUAL 5
+#define DRM_MODE_ENCODER_DSI 6
+#define DRM_MODE_ENCODER_DPMST 7
struct drm_mode_get_encoder {
__u32 encoder_id;
@@ -210,6 +213,8 @@ struct drm_mode_get_encoder {
#define DRM_MODE_CONNECTOR_HDMIB 12
#define DRM_MODE_CONNECTOR_TV 13
#define DRM_MODE_CONNECTOR_eDP14
+#define DRM_MODE_CONNECTOR_VIRTUAL 15
+#define DRM_MODE_CONNECTOR_DSI16
struct drm_mode_get_connector {
--
1.9.1
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/c4d392b0/attachment.html>
[PATCH] drm/dp-mst: Remove branches before dropping the reference
When we unplug a dp mst branch we unreference the entire tree from
the root towards the leaves. Which is ok, since that's the way the
pointers and so also the refcounts go.
But when we drop the reference we must make sure that we remove the
branches/ports from the lists/pointers before dropping the reference.
Otherwise the get_validated functions will still return it instead
of returning NULL (which indicates a potentially on-going unplug).
The mst branch destroy gets this right for ports: First it deletes
the port from the ports list, then it unrefs. But the ports destroy
function gets it wrong: First it unrefs, then it drops the ref. Which
means a zombie mst branch can still be validate with get_validated_mstb_ref
when it shouldn't.
Fix this.
This should address a backtrace Dave dug out somewhere on unplug:
[] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0
[drm_kms_helper]
[] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0
[drm_kms_helper]
[] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper]
[] drm_dp_payload_send_msg.isra.14+0x2b/0x100
[drm_kms_helper]
[] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper]
[] intel_mst_disable_dp+0x3e/0x80 [i915]
[] haswell_crtc_disable+0x1cb/0x340 [i915]
[] intel_crtc_control+0x49/0x100 [i915]
[] intel_crtc_update_dpms+0x67/0x80 [i915]
[] intel_connector_dpms+0x59/0x70 [i915]
[] intel_dp_destroy_mst_connector+0x32/0xc0 [i915]
[] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper]
[] drm_dp_destroy_mst_branch_device+0x108/0x130
[drm_kms_helper]
[] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper]
[] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper]
[] ? trace_hardirqs_on_caller+0x15d/0x200
[]
drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] []
? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] []
? intel_dp_dpcd_read_wake+0x38/0x70 [i915] []
intel_dp_check_mst_status+0xb5/0x250 [i915] []
intel_dp_hpd_pulse+0x181/0x210 [i915] []
i915_digport_work_func+0x96/0x120 [i915]
Cc: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5682d7e9f1ec..71a56d65a0d2 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -839,6 +839,8 @@ static void drm_dp_put_mst_branch_device(struct
drm_dp_mst_branch *mstb)
static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port *port, int old_pdt)
{
+ struct drm_dp_mst_branch *mstb;
+
switch (old_pdt) {
case DP_PEER_DEVICE_DP_LEGACY_CONV:
case DP_PEER_DEVICE_SST_SINK:
@@ -846,8 +848,9 @@ static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port
*port, int old_pdt)
drm_dp_mst_unregister_i2c_bus(&port->aux);
break;
case DP_PEER_DEVICE_MST_BRANCHING:
- drm_dp_put_mst_branch_device(port->mstb);
+ mstb = port_mstb;
port->mstb = NULL;
+ drm_dp_put_mst_branch_device(mstb);
break;
}
}
--
2.1.1
[Bug 87126] Fragment shader value lock up rv635 device
https://bugs.freedesktop.org/show_bug.cgi?id=87126 Bug ID: 87126 Summary: Fragment shader value lock up rv635 device Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: pavol at klacansky.com Created attachment 110596 --> https://bugs.freedesktop.org/attachment.cgi?id=110596&action=edit apitrace Changing output variable from vec4(1.0) to vec4(0.9) locks the gpu. -- 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/20141208/d153222b/attachment.html>
[Bug 85696] r600g+nine: Bioshock shader failure after 7b1c0cbc90d456384b0950ad21faa3c61a6b43ff
https://bugs.freedesktop.org/show_bug.cgi?id=85696 --- Comment #6 from David Heidelberg (okias) --- In testing repository [1] fixed by commit: st/nine: Rewrite LOOP implementation, and a0 aL handling Now it also passes wine tests without killing driver (r600g). [1] https://github.com/iXit/Mesa-3D/commits/master -- 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/20141208/f4df8bed/attachment.html>
[Bug 87059] Graphical glitches r9290
https://bugs.freedesktop.org/show_bug.cgi?id=87059 --- Comment #8 from Jarkko K --- I visited some place during night at the game, the black boxes game back on that map, but not on the starting map. -- 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/20141208/01380caf/attachment.html>
[PATCH] drm/tegra: dsi: Add suspend/resume support
This patch adds the suspend/resume support for Tegra drm
driver by calling the corresponding DPMS functions.
Signed-off-by: Mark Zhang
---
Hi,
This patch hooks DSI driver's suspend/resume to implement the whole
display system's suspend/resume. I know this is a super ugly way,
but as we all know, Tegra DRM driver doesn't have a dedicate drm device
so honestly I didn't find a better way to do that.
Thanks,
Mark
drivers/gpu/drm/tegra/dsi.c | 96 ++---
1 file changed, 90 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index 33f67fd601c6..25cd0d93f392 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -61,6 +61,9 @@ struct tegra_dsi {
struct tegra_dsi *slave;
};
+static int tegra_dsi_pad_calibrate(struct tegra_dsi *);
+static int tegra_dsi_ganged_setup(struct tegra_dsi *dsi);
+
static inline struct tegra_dsi *
host1x_client_to_dsi(struct host1x_client *client)
{
@@ -805,6 +808,20 @@ static int tegra_output_dsi_setup_clock(struct
tegra_output *output,
lanes = tegra_dsi_get_lanes(dsi);
+ err = tegra_dsi_pad_calibrate(dsi);
+ if (err < 0) {
+ dev_err(dsi->dev, "MIPI calibration failed: %d\n", err);
+ return err;
+ }
+ if (dsi->slave) {
+ err = tegra_dsi_pad_calibrate(dsi->slave);
+ if (err < 0) {
+ dev_err(dsi->slave->dev,
+ "MIPI calibration failed: %d\n", err);
+ return err;
+ }
+ }
+
err = tegra_dsi_get_muldiv(dsi->format, &mul, &div);
if (err < 0)
return err;
@@ -833,6 +850,13 @@ static int tegra_output_dsi_setup_clock(struct
tegra_output *output,
dev_err(dsi->dev, "failed to set parent clock: %d\n", err);
return err;
}
+ if (dsi->slave) {
+ err = tegra_dsi_ganged_setup(dsi);
+ if (err < 0) {
+ dev_err(dsi->dev, "DSI ganged setup failed: %d\n", err);
+ return err;
+ }
+ }
err = clk_set_rate(dsi->clk_parent, plld);
if (err < 0) {
@@ -1470,12 +1494,6 @@ static int tegra_dsi_probe(struct platform_device *pdev)
goto disable_vdd;
}
- err = tegra_dsi_pad_calibrate(dsi);
- if (err < 0) {
- dev_err(dsi->dev, "MIPI calibration failed: %d\n", err);
- goto mipi_free;
- }
-
dsi->host.ops = &tegra_dsi_host_ops;
dsi->host.dev = &pdev->dev;
@@ -1544,6 +1562,67 @@ static int tegra_dsi_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int tegra_dsi_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct tegra_dsi *dsi = platform_get_drvdata(pdev);
+ struct tegra_drm *tegra = dev_get_drvdata(dsi->client.parent);
+ struct drm_connector *connector;
+
+ if (dsi->master) {
+ regulator_disable(dsi->vdd);
+ return 0;
+ }
+
+ drm_modeset_lock_all(tegra->drm);
+ list_for_each_entry(connector, &tegra->drm->mode_config.connector_list,
+ head) {
+ int old_dpms = connector->dpms;
+
+ if (connector->funcs->dpms)
+ connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
+
+ /* Set the old mode back to the connector for resume */
+ connector->dpms = old_dpms;
+ }
+ drm_modeset_unlock_all(tegra->drm);
+
+ regulator_disable(dsi->vdd);
+
+ return 0;
+}
+
+static int tegra_dsi_resume(struct platform_device *pdev)
+{
+ struct tegra_dsi *dsi = platform_get_drvdata(pdev);
+ struct tegra_drm *tegra = dev_get_drvdata(dsi->client.parent);
+ struct drm_connector *connector;
+ int err = 0;
+
+ err = regulator_enable(dsi->vdd);
+ if (err < 0) {
+ dev_err(&pdev->dev, "Enable DSI vdd failed: %d\n", err);
+ return err;
+ }
+
+ if (dsi->master)
+ return 0;
+
+ drm_modeset_lock_all(tegra->drm);
+ list_for_each_entry(connector, &tegra->drm->mode_config.connector_list,
+ head) {
+ if (connector->funcs->dpms)
+ connector->funcs->dpms(connector, connector->dpms);
+ }
+ drm_modeset_unlock_all(tegra->drm);
+
+ drm_helper_resume_force_mode(tegra->drm);
+
+ return 0;
+}
+#endif
+
+
static const struct of_device_id tegra_dsi_of_match[] = {
{ .compatible = "nvidia,tegra114-dsi", },
{ },
@@ -1557,4 +1636,9 @@ struct platform_driver tegra_dsi_driver = {
},
.probe = tegra_dsi_probe,
.remove = tegra_dsi_remove,
+#ifdef CONFIG_PM
+ .suspend = tegra_dsi_suspend,
+ .resume = tegra_dsi_resume,
+#endif
+
};
--
[PATCH 0/20] fix misspelling of current function in string
On Mon, 8 Dec 2014, Julian Calaby wrote: > Hi Julia, > > On Mon, Dec 8, 2014 at 6:20 AM, Julia Lawall wrote: > > These patches replace what appears to be a reference to the name of the > > current function but is misspelled in some way by either the name of the > > function itself, or by %s and then __func__ in an argument list. > > Would there be any value in doing this for _all_ cases where the > function name is written in a format string? Probably. But there are a lot of them. Even for the misspellings, I have only don about 1/3 of the cases. On the other hand, the misspelling have to be checked carefully, because a misspelling of one thing could be the correct spelling of the thing thst was actually intended. Joe, however, points out that a lot of these prints are just for function tracing, and could be removed. I worked on another semantic patch that tries to do that. It might be better to remove those prints completely, rather than sending one patch to transform them and then one patch to remove them after that. That is why for this series I did only the ones where there was actually a problem. julia
[PATCH 20/20] drm/radeon: fix misspelling of current function in string
On Mon, 8 Dec 2014, Alex Deucher wrote:
> On Sun, Dec 7, 2014 at 2:21 PM, Julia Lawall wrote:
> > Replace a misspelled function name by %s and then __func__.
> >
> > This was done using Coccinelle, including the use of Levenshtein distance,
> > as proposed by Rasmus Villemoes.
> >
> > Signed-off-by: Julia Lawall
>
> Looks fine to me. For consistency, any chance you'd want to fix up
> the other places that use function names directly with this style
> patch?
I will try to do that soon.
julia
>
> Alex
>
> >
> > ---
> > The semantic patch is difficult to summarize, but is available in the cover
> > letter of this patch series.
> >
> > drivers/gpu/drm/radeon/cik.c | 16 ++--
> > 1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> > index 6dcde37..24d5e43 100644
> > --- a/drivers/gpu/drm/radeon/cik.c
> > +++ b/drivers/gpu/drm/radeon/cik.c
> > @@ -7367,34 +7367,38 @@ int cik_irq_set(struct radeon_device *rdev)
> > }
> > if (atomic_read(&rdev->irq.ring_int[CAYMAN_RING_TYPE_CP1_INDEX])) {
> > struct radeon_ring *ring =
> > &rdev->ring[CAYMAN_RING_TYPE_CP1_INDEX];
> > - DRM_DEBUG("si_irq_set: sw int cp1\n");
> > + DRM_DEBUG("%s: sw int cp1\n", __func__);
> > if (ring->me == 1) {
> > switch (ring->pipe) {
> > case 0:
> > cp_m1p0 |= TIME_STAMP_INT_ENABLE;
> > break;
> > default:
> > - DRM_DEBUG("si_irq_set: sw int cp1 invalid
> > pipe %d\n", ring->pipe);
> > + DRM_DEBUG("%s: sw int cp1 invalid pipe
> > %d\n",
> > + __func__, ring->pipe);
> > break;
> > }
> > } else {
> > - DRM_DEBUG("si_irq_set: sw int cp1 invalid me %d\n",
> > ring->me);
> > + DRM_DEBUG("%s: sw int cp1 invalid me %d\n",
> > __func__,
> > + ring->me);
> > }
> > }
> > if (atomic_read(&rdev->irq.ring_int[CAYMAN_RING_TYPE_CP2_INDEX])) {
> > struct radeon_ring *ring =
> > &rdev->ring[CAYMAN_RING_TYPE_CP2_INDEX];
> > - DRM_DEBUG("si_irq_set: sw int cp2\n");
> > + DRM_DEBUG("%s: sw int cp2\n", __func__);
> > if (ring->me == 1) {
> > switch (ring->pipe) {
> > case 0:
> > cp_m1p0 |= TIME_STAMP_INT_ENABLE;
> > break;
> > default:
> > - DRM_DEBUG("si_irq_set: sw int cp2 invalid
> > pipe %d\n", ring->pipe);
> > + DRM_DEBUG("%s: sw int cp2 invalid pipe
> > %d\n",
> > + __func__, ring->pipe);
> > break;
> > }
> > } else {
> > - DRM_DEBUG("si_irq_set: sw int cp2 invalid me %d\n",
> > ring->me);
> > + DRM_DEBUG("%s: sw int cp2 invalid me %d\n",
> > __func__,
> > + ring->me);
> > }
> > }
> >
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[UDL] NULL pointer dereference in udl_driver_unload->drm_vblank_cleanup
Dez 08 22:21:08 localhost.localdomain kernel: Restarting tasks ... done. Dez 08 22:21:08 localhost.localdomain kernel: video LNXVIDEO:00: Restoring backlight state Dez 08 22:21:08 localhost.localdomain kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Dez 08 22:21:12 localhost.localdomain kernel: IP: [< (null)>] (null) Dez 08 22:21:12 localhost.localdomain kernel: PGD 235638067 PUD 235284067 PMD 0 Dez 08 22:21:12 localhost.localdomain kernel: Oops: 0010 [#1] PREEMPT SMP Dez 08 22:21:12 localhost.localdomain kernel: Modules linked in: bluetooth fuse ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv Dez 08 22:21:12 localhost.localdomain kernel: CPU: 0 PID: 984 Comm: Xorg.bin Not tainted 3.18.0-rc6-00565-g3314bf6 #171 Dez 08 22:21:12 localhost.localdomain kernel: Hardware name: Acer Aspire 1810T/JM11-MS, BIOS v1.3310 03/25/2010 Dez 08 22:21:12 localhost.localdomain kernel: task: 8802360dd330 ti: 8800b49dc000 task.ti: 8800b49dc000 Dez 08 22:21:12 localhost.localdomain kernel: RIP: 0010:[<>] [< (null)>] (null) Dez 08 22:21:12 localhost.localdomain kernel: RSP: 0018:8800b49dfcf0 EFLAGS: 00010046 Dez 08 22:21:12 localhost.localdomain kernel: RAX: c0187140 RBX: RCX: Dez 08 22:21:12 localhost.localdomain kernel: RDX: 000a0eb2 RSI: RDI: 88009d41d000 Dez 08 22:21:12 localhost.localdomain kernel: RBP: 8800b49dfd78 R08: 8baf7fc7 R09: Dez 08 22:21:12 localhost.localdomain kernel: R10: R11: 0246 R12: 880190380dc0 Dez 08 22:21:12 localhost.localdomain kernel: R13: 0003 R14: 88009d41d000 R15: 88009693fac8 Dez 08 22:21:12 localhost.localdomain kernel: FS: 7f4fd62409c0() GS:88023fc0() knlGS: Dez 08 22:21:12 localhost.localdomain kernel: CS: 0010 DS: ES: CR0: 80050033 Dez 08 22:21:12 localhost.localdomain kernel: CR2: CR3: 000234c74000 CR4: 000407f0 Dez 08 22:21:12 localhost.localdomain kernel: Stack: Dez 08 22:21:12 localhost.localdomain kernel: 813dc235 8800b49dfd28 0086 Dez 08 22:21:12 localhost.localdomain kernel: 88009d41d188 8800b49dfd30 0282 8800b49dfd58 Dez 08 22:21:12 localhost.localdomain kernel: 0003f519 000a0eb2 c36727a9 880190380e00 Dez 08 22:21:12 localhost.localdomain kernel: Call Trace: Dez 08 22:21:12 localhost.localdomain kernel: [] ? vblank_disable_and_save+0x95/0x1f0 Dez 08 22:21:12 localhost.localdomain kernel: [] drm_vblank_cleanup+0x5d/0xa0 Dez 08 22:21:12 localhost.localdomain kernel: [] udl_driver_unload+0x13/0x50 [udl] Dez 08 22:21:12 localhost.localdomain kernel: [] drm_dev_unregister+0x28/0xb0 Dez 08 22:21:12 localhost.localdomain kernel: [] drm_put_dev+0x22/0x80 Dez 08 22:21:12 localhost.localdomain kernel: [] drm_release+0x33f/0x520 Dez 08 22:21:12 localhost.localdomain kernel: [] __fput+0xc6/0x1e0 Dez 08 22:21:12 localhost.localdomain kernel: [] fput+0x9/0x10 Dez 08 22:21:12 localhost.localdomain kernel: [] task_work_run+0x97/0xd0 Dez 08 22:21:12 localhost.localdomain kernel: [] do_notify_resume+0x59/0x80 Dez 08 22:21:12 localhost.localdomain kernel: [] int_signal+0x12/0x17 Dez 08 22:21:12 localhost.localdomain kernel: Code: Bad RIP value. Dez 08 22:21:12 localhost.localdomain kernel: RIP [< (null)>] (null) Dez 08 22:21:12 localhost.localdomain kernel: RSP Dez 08 22:21:12 localhost.localdomain kernel: CR2: Dez 08 22:21:12 localhost.localdomain kernel: ---[ end trace da2688dc2851fa3a ]--- Dez 08 22:21:12 localhost.localdomain kernel: note: Xorg.bin[984] exited with preempt_count 2
[PATCH v18 06/12] dt-bindings: add document for dw_hdmi
Hi Mark Rutland, Rob Herring, Pawel Moll, Ian Campbell, Kumar Gala:
Would you please give an Ack for this?
On 2014å¹´12æ05æ¥ 21:54, Philipp Zabel wrote:
> Am Freitag, den 05.12.2014, 14:27 +0800 schrieb Andy Yan:
>> Signed-off-by: Andy Yan
> This binding is mostly a copy of the existing
> Documentation/devicetree/bindings/drm/imx/hdmi.txt, but there is a new
> reg-io-width property to configure the register access bus width and we
> have added new compatibles "rockchip,rk3288-dw-hdmi" and the common
> "snps,dw-hdmi-tx". Could we get an Ack for this and patch 11 by the
> device tree maintainers?
>
> regards
> Philipp
>> ---
>>
>> Changes in v18:
>> - add port bindings
>> - correct some spelling mistakes in dw_hdmi bindings doc
>>
>> Changes in v17: None
>> Changes in v16:
>> - describe ddc-i2c-bus as optional
>> - add common clocks bindings
>>
>> Changes in v15: None
>> Changes in v14: None
>> Changes in v13: None
>> Changes in v12: None
>> Changes in v11: None
>> Changes in v10: None
>> Changes in v9: None
>> Changes in v8:
>> - correct some spelling mistake
>> - modify ddc-i2c-bus and interrupt description
>>
>> Changes in v7: None
>> Changes in v6: None
>> Changes in v5: None
>> Changes in v4: None
>> Changes in v3: None
>>
>> .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 50
>> ++
>> 1 file changed, 50 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> new file mode 100644
>> index 000..a905c14
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt
>> @@ -0,0 +1,50 @@
>> +DesignWare HDMI bridge bindings
>> +
>> +Required properties:
>> +- compatible: platform specific such as:
>> + * "snps,dw-hdmi-tx"
>> + * "fsl,imx6q-hdmi"
>> + * "fsl,imx6dl-hdmi"
>> + * "rockchip,rk3288-dw-hdmi"
>> +- reg: Physical base address and length of the controller's registers.
>> +- interrupts: The HDMI interrupt number
>> +- clocks, clock-names : must have the phandles to the HDMI iahb and isfr
>> clocks,
>> + as described in
>> Documentation/devicetree/bindings/clock/clock-bindings.txt,
>> + the clocks are soc specific, the clock-names should be "iahb", "isfr"
>> +-port@[X]: SoC specific port nodes with endpoint definitions as defined
>> + in Documentation/devicetree/bindings/media/video-interfaces.txt,
>> + please refer to the SoC specific binding document:
>> +* Documentation/devicetree/bindings/drm/imx/hdmi.txt
>> +* Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt
>> +
>> +Optional properties
>> +- reg-io-width: the width of the reg:1,4, default set to 1 if not present
>> +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
>> +- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec"
>> +
>> +Example:
>> +hdmi: hdmi at 012 {
>> +compatible = "fsl,imx6q-hdmi";
>> +reg = <0x0012 0x9000>;
>> +interrupts = <0 115 0x04>;
>> +gpr = <&gpr>;
>> +clocks = <&clks 123>, <&clks 124>;
>> +clock-names = "iahb", "isfr";
>> +ddc-i2c-bus = <&i2c2>;
>> +
>> +port at 0 {
>> +reg = <0>;
>> +
>> +hdmi_mux_0: endpoint {
>> +remote-endpoint = <&ipu1_di0_hdmi>;
>> +};
>> +};
>> +
>> +port at 1 {
>> +reg = <1>;
>> +
>> +hdmi_mux_1: endpoint {
>> +remote-endpoint = <&ipu1_di1_hdmi>;
>> +};
>> +};
>> +};
>
>
>
>
[PATCH] add support for AM572x in the DDX
On 06/12/14 21:19, Robert Nelson wrote: >> gotcha, well I've pushed your patch. I don't really have the hw >> unpacked and setup to test these days, but if someone confirm latest >> master is good then I suppose I should spin a release tag for distro's >> to pick up.. > > Thanks Rob! > > I'll test and re-confirm on my x15 alpha board when i'm back in the > lab on monday. I tested xf86-video-omap HEAD on my dra7-evm, and X starts fine now. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141208/3c0a1f9e/attachment.sig>
Long radeon stalls on recent kernels
On Wed, Nov 26, 2014 at 7:38 AM, Andy Lutomirski wrote: > On Tue, Nov 25, 2014 at 10:42 PM, Michel Dänzer > wrote: >> On 20.11.2014 09:58, Andy Lutomirski wrote: >>> >>> On Wed, Nov 19, 2014 at 4:07 PM, Andy Lutomirski >>> wrote: On Tue, Nov 18, 2014 at 11:19 PM, Michel Dänzer wrote: > > On 19.11.2014 09:21, Andy Lutomirski wrote: >> >> >> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer >> wrote: >>> >>> >>> On 15.11.2014 07:21, Andy Lutomirski wrote: On recent kernels (3.16 through 3.18-rc4, perhaps), doing anything graphics intensive seems to cause my system to become unusable for tens of seconds. Pointing Firefox at Google Maps is a big offender -- it can take several minutes for me to move my mouse far enough to close the tab and get my computer back. On bootup, I get this warning: [drm:btc_dpm_set_power_state] *ERROR* rv770_restrict_performance_levels_before_switch failed Setting radeon.dpm=0 seems to work around this problem at the cost of giving my rather slow graphics. Are there known issues here? >>> >>> >>> >>> >>> Can you bisect the kernel, or at least isolate which kernel version >>> first >>> introduced the problem? >> >> >> >> With whatever userspace I'm running, I'm seeing it 3.13, 3.14, 3.15, >> 3.16, and 3.18-rc4+. I haven't tried other versions. >> >> With radeon.dpm=0, I can still trigger short stalls (around one >> second), but I seem unable to trigger long stalls easily. (I say >> easily because, just as I was typing this email, my system stalled for >> about a minute.) > > > > I can only think of two things offhand that could cause such extremely > long > stalls: Swap thrashing or IRQ storms. > > With a setup where you can easily trigger long stalls, can you try > getting a > CPU profile for a stall with sysprof or perf? > > Got one with perf: 16.82% Xorg libc-2.18.so[.] __memcpy_sse2_unaligned 9.20% swapper [kernel.kallsyms] [k] intel_idle 1.00% Xorg [kernel.kallsyms] [k] evergreen_irq_set 0.83% firefox libxul.so [.] 0x01d93281 0.69% firefox libxul.so [.] 0x01d932ad 0.62% firefox [kernel.kallsyms] [k] copy_user_generic_string 0.55% swapper [kernel.kallsyms] [k] evergreen_irq_ack 0.54% firefox libpthread-2.18.so [.] pthread_mutex_lock 0.52% firefox libpthread-2.18.so [.] pthread_mutex_unlock 0.45% Xorg [kernel.kallsyms] [k] drm_mm_insert_node_in_range_generic 0.41% Xorg [kernel.kallsyms] [k] lock_release 0.40% Xorg [kernel.kallsyms] [k] lock_acquire 0.35% firefox firefox [.] 0x0001245d 0.33% Xorg [kernel.kallsyms] [k] __module_address 0.31% firefox [kernel.kallsyms] [k] clear_page_c 0.29% Xorg [kernel.kallsyms] [k] copy_user_generic_string 0.28% firefox firefox [.] 0x00013159 and: Samples: 11K of event 'irq:irq_handler_entry', Event count (approx.): 11802 87.43% swapper [kernel.kallsyms] [k] handle_irq_event_percpu 7.52% firefox [kernel.kallsyms] [k] handle_irq_event_percpu 1.84% irq/36-ahci [kernel.kallsyms] [k] handle_irq_event_percpu 1.14% Xorg [kernel.kallsyms] [k] handle_irq_event_percpu 0.75% kworker/5:0 [kernel.kallsyms] [k] handle_irq_event_percpu 0.32% gnome-shell [kernel.kallsyms] [k] handle_irq_event_percpu 0.25% kworker/5:1H [kernel.kallsyms] [k] handle_irq_event_percpu 0.25% Media D~ode #10 [kernel.kallsyms] [k] handle_irq_event_percpu 0.19% ImageDe~er #330 [kernel.kallsyms] [k] handle_irq_event_percpu 0.07% pulseaudio [kernel.kallsyms] [k] handle_irq_event_percpu The cycles were with -e cycles:pp, so I think that iret would have shown up if there were enough IRQs to cause the problem. I'll build a kernel with latencytop. >>> >>> I just caught call_rwsem_down_write_fa
