attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/b0bd4c29/attachment.html>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/c704fbed/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/1edaa69b/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=90861
--- Comment #10 from Alex Deucher ---
Possibly related to bug 90741.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90861
--- Comment #9 from Jon Arne Jørgensen ---
Finaly managed to get a clean bisect, this is the culprit:
commit f2c24b83ae90292d315aa7ac029c6ce7929e01aa
Author: Maarten Lankhorst
Date: Wed Apr 2 17:14:48 2014 +0200
drm/ttm: flip the switch,
On Thu, Jan 22, 2015 at 06:38:32PM +0100, Daniel Vetter wrote:
> On Thu, Jan 22, 2015 at 5:42 PM, Ville Syrjälä
> wrote:
> >> Which is pretty much what I do - you can only access the per-crtc ACTIVE
> >> property from the atomic ioctl, the per-connector dpms property is _not_
> >> exposed throug
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #18 from Gustaw Smolarczyk ---
Only the second version (with the 2 lines uncommented) of the new patch does
fix the problem.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #17 from Maarten Lankhorst ---
Created attachment 164421
--> https://bugzilla.kernel.org/attachment.cgi?id=164421&action=edit
Another approach
Don't need to test anything but final version, can you test this version
though? I want t
oreal kernel: [drm] ib test on ring 3 succeeded in 0 usecs
--
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/20150122/27f0313a/attachment.html>
esktop.org/archives/dri-devel/attachments/20150122/c4287a7d/attachment.html>
On 22.01.2015 18:06, Christian König wrote:
> Am 22.01.2015 um 08:30 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> The GART table BO has to be moved out of VRAM for suspend/resume. Any
>> updates to the GART table during that time were silently dropped without
>> this change. This caused
From: Michel Dänzer
The GART table BO has to be moved out of VRAM for suspend/resume. Any
updates to the GART table during that time were silently dropped without
this change. This caused GPU lockups on resume in some cases, see the bug
reports referenced below.
This might also make GPU reset m
This builds on top of the crtc->active infrastructure to implement
legacy DPMS. My choice of semantics is somewhat arbitrary, but the
entire pipe is enabled as along as one output is still enabled.
Of course it also clamps everything that's not ON to OFF.
v2: Fix spelling in one comment.
v3: Don
On 22.01.2015 18:28, Michel Dänzer wrote:
> On 22.01.2015 18:08, Christian König wrote:
>> Am 22.01.2015 um 08:31 schrieb Michel Dänzer:
>>> On 21.01.2015 18:22, Christian König wrote:
Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> The GART table BO
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/9b075d86/attachment.html>
://github.com/iXit/Mesa-3D/issues/64 ) the shader seems fine, it is likely
a r300 compiler error.
--
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-
On Thu, Jan 22, 2015 at 05:15:26PM +0100, Daniel Vetter wrote:
> On Thu, Jan 22, 2015 at 05:56:54PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 22, 2015 at 04:36:21PM +0100, Daniel Vetter wrote:
> > > This is the infrastructure for DPMS ported to the atomic world.
> > > Fundamental changes compar
On Thu, Jan 22, 2015 at 5:42 PM, Ville Syrjälä
wrote:
>> Which is pretty much what I do - you can only access the per-crtc ACTIVE
>> property from the atomic ioctl, the per-connector dpms property is _not_
>> exposed through atomic. Vice-versa legacy clients wont see atomic
>> properties (and he
there is a Bug that:
vop_enable()->drm_vblank_on, drm_vblank_on may call vop
enable vblank. if it happen, vblank enable would failed,
then cause irq status error. because is_enabled value is set
after drm_vblank_on.
after enable vop clocks and iommu regs, we can sure that
R/W vop regs and do vop
drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
--> DRM_DPMS_ON: power on vop
--> DRM_DPMS_SUSPEND: power off vop
--> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.
Signed-off-by: Mar
drm dpms have many power modes, ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
--> DRM_DPMS_ON: power on vop
--> DRM_DPMS_SUSPEND: power off vop
--> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.
another problem at
On 22.01.2015 18:08, Christian König wrote:
> Am 22.01.2015 um 08:31 schrieb Michel Dänzer:
>> On 21.01.2015 18:22, Christian König wrote:
>>> Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
From: Michel Dänzer
The GART table BO has to be moved out of VRAM for suspend/resume. Any
On Thu, Jan 22, 2015 at 04:36:21PM +0100, Daniel Vetter wrote:
> This is the infrastructure for DPMS ported to the atomic world.
> Fundamental changes compare to legacy DPMS are:
>
> - No more per-connector dpms state, instead there's just one per each
> display pipeline. So if you clone either
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/640988c4/attachment.html>
ernel from the grub menu.
--
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/20150122/880ce3a0/attachment.html>
On Thu, Jan 22, 2015 at 05:56:54PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 22, 2015 at 04:36:21PM +0100, Daniel Vetter wrote:
> > This is the infrastructure for DPMS ported to the atomic world.
> > Fundamental changes compare to legacy DPMS are:
> >
> > - No more per-connector dpms state, inst
Add CEC interface driver present in the Samsung Exynos range of
SoCs.
The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c
Signed-off-by: Kamil Debski
---
drivers/media/platform/Kconfig |7 +
drivers/media/platform/Makefile
From: Hans Verkuil
Add CEC support to the adv7511 driver.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
Signed-off-by: Kamil Debski
---
drivers/media/i2c/adv7511.c | 325 ++-
include/medi
From: Hans Verkuil
Add CEC support ot the adv7604 driver.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
Signed-off-by: Kamil Debski
---
drivers/media/i2c/adv7604.c | 182 +++
1 file chang
From: Hans Verkuil
Add callbacks to the v4l2_subdev_video_ops.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
Signed-off-by: Kamil Debski
---
include/media/v4l2-subdev.h |8
1 file changed, 8 insertions(+)
diff --gi
Add the CEC framework.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
[k.debski at samsung.com: change kthread handling when setting logical
address]
[k.debski at samsung.com:
Add cec protocol handling the RC framework.
Signed-off-by: Kamil Debski
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-cec.c | 133 +
drivers/media/rc/rc-main.c|1 +
include/media/rc-core.h |1 +
include/
Add device tree node for the s5p-cec hdmi CEC driver.
Signed-off-by: Kamil Debski
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi |7 +++
arch/arm/boot/dts/exynos4412-odroidu3.dts | 13 +
2 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412
Hi,
This is the second version of my attempt at the CEC framework patches.
As mentioned in the previous cover letter the original work was done by
Hans Verkuil, but he was short of time and the CEC framework was stalled
for some time. The original cover letter attached below will surely shed
more
2015-01-20 Thierry Reding :
> From: Thierry Reding
>
> In order to prevent drivers from having to perform the same checks over
> and over again, add an optional ->atomic_disable callback which the core
> calls under the right circumstances.
>
> v2: pass old state and detect edges to avoid calli
On 2015å¹´01æ22æ¥ 15:33, Daniel Vetter wrote:
> On Thu, Jan 22, 2015 at 03:05:32PM +0800, Mark Yao wrote:
>> drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
>> but vop only have enable/disable mode, maybe case such bug:
>> --> DRM_DPMS_ON: power on vop
>> --> DRM_DPMS_SUSPEND: p
Hello,
On 2015ë
01ì 22ì¼ 07:46, Tobias Jakobi wrote:
> Hello!
>
>
> Inki Dae wrote:
>> The use of spin lock, reg_slock, has been used for a long time and we
>> hadn't some cleanups to spin lock codes so far. The spin lock is also
>> used in here and there of mixer driver. And at least, it s
With the combination of ->enable and ->active it's a bit complicated
to follow what exactly is going on sometimes within a full modeset.
Add debug output to make this all traceable.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 22 +-
1 file changed,
For historical reasons going all the way back to how the Xrandr code
was implemented the semantics of the callbacks used to enable/disable
crtcs and encoders are ... interesting.
But with atomic helpers all that complexity has been binned, with only
a well-defined on/off action left. Unfortunately
Cursor plane updates have historically been fully async and mutliple
updates batched together for the next vsync. And userspace relies upon
that. Since implementing a full queue of async atomic updates is a bit
of work lets just recover the cursor specific behaviour with a hint
flag and some hacks
This builds on top of the crtc->active infrastructure to implement
legacy DPMS. My choice of semantics is somewhat arbitrary, but the
entire pipe is enabled as along as one output is still enabled.
Of course it also clamps everything that's not ON to OFF.
v2: Fix spelling in one comment.
Signed-
This is the infrastructure for DPMS ported to the atomic world.
Fundamental changes compare to legacy DPMS are:
- No more per-connector dpms state, instead there's just one per each
display pipeline. So if you clone either you have to unclone first
if you only want to switch off one screen, or
On 21.01.2015 18:22, Christian König wrote:
> Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> The GART table BO has to be moved out of VRAM for suspend/resume. Any
>> updates to the GART table during that time were silently dropped without
>> this change. This caused
From: Michel Dänzer
The GART table BO has to be moved out of VRAM for suspend/resume. Any
updates to the GART table during that time were silently dropped without
this change. This caused GPU lockups on resume in some cases, see the bug
reports referenced below.
This might also make GPU reset m
I looks good for me.
Ack-by: benjamin.gaignard at linaro.org
2015-01-17 8:18 GMT+01:00 Jassi Brar :
> copy-paste wasn't followed by editing, do it.
>
> Signed-off-by: Jassi Brar
> ---
> drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/driv
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/19372244/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=91371
--- Comment #5 from Adis HamziÄ ---
I just tested the kernels 3.14.27 and 3.16.7.3 and they both display the issue.
Now, I had used the 3.14.27 kernel for at least 10 days and I never noticed
this issue. In that time I was doing some kernel de
When page flipping, we need to mark the new fb as active and unmark the active
flag for the old fb (if different).
Signed-off-by: Haixia Shi
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/udl/udl_modeset.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers
Hi Jammy, All,
On 21 January 2015 at 23:04, Alex Deucher wrote:
> On Wed, Jan 21, 2015 at 12:30 PM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> On 21-01-15 17:16, Alex Deucher wrote:
>>> On Wed, Jan 21, 2015 at 5:31 AM, Maarten Lankhorst
>>> wrote:
Op 21-01-15 om 11:35 schreef Jammy Zhou:
>>
From: Colin Ian King
cppcheck on lines 917 and 977 show an ineffective assignment
to the dma buffer pointer:
[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]:
[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]:
(warning) Assignment of function parameter has no effect
outside the function. Did you fo
there is a Bug that:
vop_enable()->drm_vblank_on, drm_vblank_on may call vop
enable vblank. if it happen, vblank enable would failed,
then cause irq status error. because is_enabled value is set
after drm_vblank_on.
after enable vop clocks and iommu regs, we can sure that
R/W vop regs and do vop
drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
--> DRM_DPMS_ON: power on vop
--> DRM_DPMS_SUSPEND: power off vop
--> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.
Signed-off-by: Mar
drm dpms have many power modes, ON,OFF,SUSPEND,STANDBY, etc.
but vop only have enable/disable mode, maybe case such bug:
--> DRM_DPMS_ON: power on vop
--> DRM_DPMS_SUSPEND: power off vop
--> DRM_DPMS_OFF: already power off at SUSPEND, crash
so use a bool val is more suitable.
another problem at
On Thu, Jan 22, 2015 at 04:56:09PM +0800, Mark yao wrote:
> On 2015å¹´01æ22æ¥ 15:33, Daniel Vetter wrote:
> >On Thu, Jan 22, 2015 at 03:05:32PM +0800, Mark Yao wrote:
> >>drm dpms have many power modes: ON,OFF,SUSPEND,STANDBY, etc.
> >>but vop only have enable/disable mode, maybe case such bug:
Hello,
On 2015-01-22 13:51, Javier Martinez Canillas wrote:
> Hello Marek,
>
> On 01/22/2015 01:41 PM, Marek Szyprowski wrote:
+ mixer_res->hdmi = devm_clk_get(dev, "hdmi");
>>> You need to update the
>>> Documentation/devicetree/bindings/video/exynos_mixer.txt
>>> DT binding docs
Hello Marek,
On 01/22/2015 01:28 PM, Marek Szyprowski wrote:
> Mixed need to have hdmi clock enabled to properly perform power on/off
> sequences, so add handling of this clock directly to the mixer driver.
> Dependency between hdmi clock and mixer module has been observed on
> Exynos4 based board
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16 ++---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 28 ++
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 20 +---
3 files changed, 27 insertions(+), 37 del
Hello Marek,
On 01/22/2015 01:41 PM, Marek Szyprowski wrote:
>>>
>>> + mixer_res->hdmi = devm_clk_get(dev, "hdmi");
>> You need to update the
>> Documentation/devicetree/bindings/video/exynos_mixer.txt
>> DT binding docs to also mention the "hdmi" clock in the list of clocks.
>
> Right, I'v
Hello,
On 2015-01-20 13:52, Javier Martinez Canillas wrote:
> On 01/20/2015 01:16 PM, Marek Szyprowski wrote:
>> Mixed need to have hdmi clock enabled to properly perform power on/off
>> sequences, so add handling of this clock directly to the mixer driver.
>> Dependency between hdmi clock and mix
Mixed need to have hdmi clock enabled to properly perform power on/off
sequences, so add handling of this clock directly to the mixer driver.
Dependency between hdmi clock and mixer module has been observed on
Exynos4 based boards.
Suggested-by: Andrzej Hajda
Signed-off-by: Marek Szyprowski
---
This patch fixes a bug where the first_pipe index passed into init_pipelines()
was a #define instead of the value that is passed into amdkfd by radeon
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This patch fixes a bug when calling to init_pipeline() interface.
The index that was passed to that function didn't take into account the
first_pipe value, which represents the first pipe index that is under amdkfd's
responsibility.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_d
This patch fixes the behavior of kgd_init_pipeline in that this function
shouldn't automatically increase the pipe_id argument by 1 right at the start
of the function.
This is because the first_pipe value might not be always 1, and because a
proper interface function should not hide this info insi
Following comments on original patch, I prepared this patch-set to address
all the issues that were brought up.
Oded
Oded Gabbay (3):
drm/radeon: Don't increment pipe_id in kgd_init_pipeline
drm/amdkfd: Fix bug in pipelines initialization
drm/amdkfd: Fix bug in call to init_pipeline
On 01/22/2015 12:22 PM, Zhou, Jammy wrote:
> Hi Oded,
>
> - pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
> + pipe_hpd_addr = dqm->pipelines_addr + inx * CIK_HPD_EOP_BYTES;
> I think 'i' should still be used here, because it is the real index in the
> buffe
On 01/22/2015 12:28 PM, Zhou, Jammy wrote:
> Patches are Reviewed-by: Jammy Zhou
>
> Regards,
> Jammy
>
Thanks!
Oded
> -Original Message-
> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
> Of Gabbay, Oded
> Sent: Thursday, January 22, 2015 5:42 PM
On 01/22, Thierry Reding wrote:
> On Wed, Jan 21, 2015 at 04:16:05PM -0800, Stephen Boyd wrote:
> > On 01/21/2015 08:13 AM, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > This new function is similar to clk_set_parent(), except that it doesn't
> > > actually change the parent. It mer
Hi Dave,
Suspend/resume regression fix for 3.19.
The following changes since commit 67cf2d391292f8bf0598236e7b4ec343eae6234f:
Merge tag 'drm-amdkfd-fixes-2015-01-13' of
git://people.freedesktop.org/~gabbayo/linux into drm-fixes (2015-01-21 09:26:47
+1000)
are available in the git repository
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/ecfa9222/attachment.html>
Hi Dave
I'd like this patch, some gem object need not be mapped into kernel
address space.
The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470:
Merge remote-tracking branch 'origin/master' into drm-next
(2015-01-22 10:44:41 +1000)
are available in the git reposi
On Wed, Jan 21, 2015 at 3:36 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> get_page_entry calculates the GART page table entry, which is just written
> to the GART page table by set_page_entry.
>
> This is a prerequisite for the following fix.
>
> Cc: stable at vger.kernel.org
> Signed-off
Mark,
å¨ 2015å¹´01æ22æ¥ 11:15, Mark Yao åé:
> Vop set wrong vsync/hsync polarity, it may cause some
> display problem. known problem is that caused HDMI hdcp
> authenticate failed, caused pixel offset with hdmi display.
> the polarity description at RK3288 TRM doc:
>dsp_vsync_pol
>
On 01/22/2015 01:47 AM, Dave Airlie wrote:
> On 21 January 2015 at 22:38, Oded Gabbay wrote:
>> Hi Dave,
>>
>> Another pull request for 3.20.
>>
>> drm-amdkfd-next-2015-01-21:
>>
>> - Infrastructure work in amdkfd to prepare for VI support. This work mainly
>>includes separating modules into
Hi Dave,
Radeon drm-next changes for 3.20. Highlights:
- Indirect draw support for evergreen/NI hw
- SMC fan control support for SI/CI
- Manual fan control for SI/CI
- DP audio support
- Lots of code cleanup
The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470:
Merge re
This patch handles a case where amdkfd tries to destroy a queue but the queue
type is invalid.
This case occurs in non-HWS path.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkf
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 3 +++
drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_devic
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index a5c69e9..23a1e95 100644
---
Am 22.01.2015 um 10:58 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> The GART table BO has to be moved out of VRAM for suspend/resume. Any
> updates to the GART table during that time were silently dropped without
> this change. This caused GPU lockups on resume in some cases, see the bug
> r
On Thu, Jan 22, 2015 at 11:15 AM, Mark Yao wrote:
> Vop set wrong vsync/hsync polarity, it may cause some
> display problem. known problem is that caused HDMI hdcp
> authenticate failed, caused pixel offset with hdmi display.
> the polarity description at RK3288 TRM doc:
> dsp_vsync_pol
> VS
Vop set wrong vsync/hsync polarity, it may cause some
display problem. known problem is that caused HDMI hdcp
authenticate failed, caused pixel offset with hdmi display.
the polarity description at RK3288 TRM doc:
dsp_vsync_pol
VSYNC polarity
1'b0 : negative
1'b1 : positive
This patch fixes a bug when calling to init_pipeline() interface.
The index that was passed to that function didn't take into account the
first_pipe value, which represents the first pipe index that is under amdkfd's
responsibility.
Signed-off-by: Oded Gabbay
---
drivers/gpu/drm/amd/amdkfd/kfd_d
On Tue, Jan 20, 2015 at 10:16 AM, Marek Szyprowski
wrote:
> + mixer_res->hdmi = devm_clk_get(dev, "hdmi");
> + if (IS_ERR(mixer_res->hdmi)) {
> + dev_err(dev, "failed to get clock 'hdmi'\n");
> + return -ENODEV;
'return PTR_ERR(mixer_res->hdmi);' would be
On Thu, Jan 22, 2015 at 5:59 AM, Oded Gabbay wrote:
> This patch fixes the behavior of kgd_init_pipeline in that this function
> shouldn't automatically increase the pipe_id argument by 1 right at the start
> of the function.
>
> This is because the first_pipe value might not be always 1, and beca
On Thu, Jan 22, 2015 at 5:59 AM, Oded Gabbay wrote:
> This patch fixes a bug when calling to init_pipeline() interface.
> The index that was passed to that function didn't take into account the
> first_pipe value, which represents the first pipe index that is under amdkfd's
> responsibility.
>
> S
ves/dri-devel/attachments/20150122/620d0d5e/attachment.html>
On Thu, Jan 22, 2015 at 5:59 AM, Oded Gabbay wrote:
> This patch fixes a bug where the first_pipe index passed into init_pipelines()
> was a #define instead of the value that is passed into amdkfd by radeon
>
> Signed-off-by: Oded Gabbay
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/a
On Thu, Jan 22, 2015 at 6:55 AM, Oded Gabbay wrote:
> Signed-off-by: Oded Gabbay
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 16 ++---
> .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 28
> ++
> .../gpu/drm/amd/amdk
https://bugzilla.kernel.org/show_bug.cgi?id=91371
--- Comment #4 from Adis HamziÄ ---
(In reply to Michel Dänzer from comment #3)
> (In reply to Adis HamziÄ from comment #2)
> > Have the same issue since my kernel update yesterday.
>
> What kernel version did you update from? Can you bisect?
On Wed, Jan 21, 2015 at 5:49 PM, Rob Clark wrote:
> In cases where MMU_NOTIFIER is not available, userptr will not be
> available. Similar to i915, although not making an exception for
> CAP_SYS_ADMIN.
>
> The proposed userspace patches for userptr seem to handle the fall-
> back properly, so a u
Patches are Reviewed-by: Jammy Zhou
Regards,
Jammy
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Gabbay, Oded
Sent: Thursday, January 22, 2015 5:42 PM
To: dri-devel at lists.freedesktop.org
Subject: [PATCH 3/3] drm/amdkfd: Handle case o
Hi Oded,
- pipe_hpd_addr = dqm->pipelines_addr + i * CIK_HPD_EOP_BYTES;
+ pipe_hpd_addr = dqm->pipelines_addr + inx * CIK_HPD_EOP_BYTES;
I think 'i' should still be used here, because it is the real index in the
buffer
Besides, for the code below in init_scheduler(),
Am 22.01.2015 um 08:31 schrieb Michel Dänzer:
> On 21.01.2015 18:22, Christian König wrote:
>> Am 21.01.2015 um 09:36 schrieb Michel Dänzer:
>>> From: Michel Dänzer
>>>
>>> The GART table BO has to be moved out of VRAM for suspend/resume. Any
>>> updates to the GART table during that time were
Am 22.01.2015 um 08:30 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> The GART table BO has to be moved out of VRAM for suspend/resume. Any
> updates to the GART table during that time were silently dropped without
> this change. This caused GPU lockups on resume in some cases, see the bug
> r
f
that improves my understanding.
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/20150122/d6ed604e/attachment.sig>
espin because of that.
Reviewed-by: Thierry Reding
-- 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/20150122/c6f75ee2/attachment.sig>
On 21 January 2015 at 22:38, Oded Gabbay wrote:
> Hi Dave,
>
> Another pull request for 3.20.
>
> drm-amdkfd-next-2015-01-21:
>
> - Infrastructure work in amdkfd to prepare for VI support. This work mainly
> includes separating modules into ASIC-specific functionality, adding
> new properties
:
Reviewed-by: Thierry Reding
-- 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/20150122/8721f6b7/attachment.sig>
Am Dienstag, den 20.01.2015, 20:44 -0200 schrieb Fabio Estevam:
> From: Fabio Estevam
>
> In the case of errors we should propagate them.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v2:
> - Propage the error in more places like suggested by Philipp
Thank you, I have queued this patc
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150122/4b87e0f2/attachment.html>
Hi Robin!
On 22 January 2015 at 00:26, Robin Murphy wrote:
> Hi Sumit,
>
>
> On 21/01/15 04:16, Sumit Semwal wrote:
>>
>> From: Rob Clark
>>
>> For devices which have constraints about maximum number of segments in
>> an sglist. For example, a device which could only deal with contiguous
>> buf
1 - 100 of 109 matches
Mail list logo
