dri-devel December 2014

dri-devel@lists.freedesktop.org

156 participants
1053 discussions

[PATCH 1/1] amdkfd: Fixing topology bug in building sysfs nodes
by Oded Gabbay 14 Dec '14

14 Dec '14

From: Ben Goz <ben.goz(a)amd.com> Original code sent always 0 as the index number of the node. This patch fixes this bug by sending a variable which is incremented per node. Signed-off-by: Ben Goz <ben.goz(a)amd.com> Reviewed-by: Oded Gabbay <oded.gabbay(a)amd.com> --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c index b11792d..cca1708 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c @@ -921,7 +921,7 @@ static int kfd_build_sysfs_node_tree(void) uint32_t i = 0; list_for_each_entry(dev, &topology_device_list, list) { - ret = kfd_build_sysfs_node_entry(dev, 0); + ret = kfd_build_sysfs_node_entry(dev, i); if (ret < 0) return ret; i++; -- 1.9.1

1 0

[PATCH v2 1/1] amdkfd: fix error printing in kfd_ioctl()
by Oded Gabbay 14 Dec '14

14 Dec '14

When an ioctl function returns -EAGAIN, don't print error in kfd_ioctl() v2: Also don't print an error if the ioctl function returns -ERESTARTSYS Signed-off-by: Oded Gabbay <oded.gabbay(a)amd.com> --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c index 7d4974b..e10b5b9 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c @@ -571,7 +571,7 @@ static long kfd_ioctl(struct file *filep, unsigned int cmd, unsigned long arg) break; } - if (err < 0) + if ((err < 0) && (err != -EAGAIN) && (err != -ERESTARTSYS)) dev_err(kfd_device, "ioctl error %ld for ioctl cmd 0x%x (#%d)\n", err, cmd, _IOC_NR(cmd)); -- 1.9.1

1 0

[PATCH 0/6] Add SDMA user-mode queues support to amdkfd
by Oded Gabbay 14 Dec '14

14 Dec '14

This patch-set enables amdkfd to provide the ability to HSA processes to create SDMA user-mode queues. The queues can be scheduled on either one of Kaveri's two SDMA engines. The assignment is done during the creation of the queue and it is alternating between the first engine and the second. e.g. first SDMA queue will be assigned to engine 1, second SDMA queue will be assigned to engine 2, third SDMA queue will be assigned to engine 1 and so forth. The creation and destruction of the queues is done through the same IOCTLs that are used to create regular compute queues. The identification in the create queue ioctl is done by using the queue_type argument that is passed by the HSA process to the amdkfd. That argument is already present in the current interface so it is backward compatible. The patch-set adds four new functions to the interface between kfd and kgd. Three of those functions are used only in no-HWS mode, which is used when during debug and bring-up. The main abstraction is done at the MQD level, which has a different layout than a compute MQD. Oded Gabbay Ben Goz (6): drm/amd: Add SDMA functions to kfd-->kgd interface drm/radeon: Implement SDMA interface functions amdkfd: Add SDMA mqd support amdkfd: Add SDMA user-mode queues support to QCM amdkfd: Identify SDMA queue in create queue ioctl amdkfd: Pass queue type to pqm_create_queue() drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 6 +- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 167 ++++++++++++++++- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 5 + drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c | 121 +++++++++++++ drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 8 + .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 2 +- drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 17 +- drivers/gpu/drm/radeon/cik_reg.h | 200 ++++++++++++++++++++- drivers/gpu/drm/radeon/radeon_kfd.c | 132 +++++++++++++- 9 files changed, 641 insertions(+), 17 deletions(-) -- 1.9.1

1 6

[PATCH 1/3] drm/amd: Add get_fw_version to kfd-->kgd interface
by Oded Gabbay 14 Dec '14

14 Dec '14

From: Alexey Skidanov <Alexey.Skidanov(a)amd.com> This patch adds a new interface to the kfd-->kgd interface. The new interface function retrieves the firmware version that is currently in use by the MEC engine. The firmware was uploaded to the MEC engine by the kgd (radeon). Signed-off-by: Alexey Skidanov <Alexey.Skidanov(a)amd.com> Reviewed-by: Oded Gabbay <oded.gabbay(a)amd.com> --- drivers/gpu/drm/amd/include/kgd_kfd_interface.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h index 9c729dd..07f694b 100644 --- a/drivers/gpu/drm/amd/include/kgd_kfd_interface.h +++ b/drivers/gpu/drm/amd/include/kgd_kfd_interface.h @@ -137,6 +137,8 @@ struct kgd2kfd_calls { * * @hqd_destroy: Destructs and preempts the queue assigned to that hqd slot. * + * @get_fw_version: Returns FW versions from the header + * * This structure contains function pointers to services that the kgd driver * provides to amdkfd driver. * @@ -176,6 +178,7 @@ struct kfd2kgd_calls { int (*hqd_destroy)(struct kgd_dev *kgd, uint32_t reset_type, unsigned int timeout, uint32_t pipe_id, uint32_t queue_id); + uint16_t (*get_fw_version)(struct kgd_dev *kgd); }; bool kgd2kfd_init(unsigned interface_version, -- 1.9.1

2 4

[PATCH] drm: sti: fix module compilation issue
by Benjamin Gaignard 13 Dec '14

13 Dec '14

When compiling in module some symbol aren't missing, export them correctly. Signed-off-by: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> --- drivers/gpu/drm/sti/sti_drm_plane.c | 1 + drivers/gpu/drm/sti/sti_hqvdp.c | 1 + drivers/gpu/drm/sti/sti_layer.c | 2 ++ 3 files changed, 4 insertions(+) diff --git a/drivers/gpu/drm/sti/sti_drm_plane.c b/drivers/gpu/drm/sti/sti_drm_plane.c index c9dd0e5..bb6a293 100644 --- a/drivers/gpu/drm/sti/sti_drm_plane.c +++ b/drivers/gpu/drm/sti/sti_drm_plane.c @@ -194,3 +194,4 @@ struct drm_plane *sti_drm_plane_init(struct drm_device *dev, return &layer->plane; } +EXPORT_SYMBOL(sti_drm_plane_init); diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c index 200d020..f3db05d 100644 --- a/drivers/gpu/drm/sti/sti_hqvdp.c +++ b/drivers/gpu/drm/sti/sti_hqvdp.c @@ -816,6 +816,7 @@ struct sti_layer *sti_hqvdp_create(struct device *dev) return &hqvdp->layer; } +EXPORT_SYMBOL(sti_hqvdp_create); static void sti_hqvdp_init_plugs(struct sti_hqvdp *hqvdp) { diff --git a/drivers/gpu/drm/sti/sti_layer.c b/drivers/gpu/drm/sti/sti_layer.c index 480ec1c..899104f 100644 --- a/drivers/gpu/drm/sti/sti_layer.c +++ b/drivers/gpu/drm/sti/sti_layer.c @@ -40,6 +40,7 @@ const char *sti_layer_to_str(struct sti_layer *layer) return "<UNKNOWN LAYER>"; } } +EXPORT_SYMBOL(sti_layer_to_str); struct sti_layer *sti_layer_create(struct device *dev, int desc, void __iomem *baseaddr) @@ -77,6 +78,7 @@ struct sti_layer *sti_layer_create(struct device *dev, int desc, return layer; } +EXPORT_SYMBOL(sti_layer_create); int sti_layer_prepare(struct sti_layer *layer, struct drm_crtc *crtc, -- 1.9.1

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 13 Dec '14

13 Dec '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #72 from Martin Peres <martin.peres(a)ensi-bourges.fr> --- Hey Oleg, (In reply to Chernovsky Oleg from comment #68) > (In reply to Martin Peres from comment #66) > > Martin, there're things I think I didn't get correctly: > - What should I return if pwm1_enable is 0 and I'm trying to push 50 into > pwm1? I made Nouveau return -EINVAL. > - Can pwm1_enabled value be 2 after I push 0 to it? Radeon default fan value > comes from fuse and it's not 100% So, you mean that the boot default for the fan mode is the automatic mode, right? That's perfectly fine. The only thing you need to make sure of is that when the user writes 0 to pwm1_enable, you should disable auto fan management and set the fan speed to 100%. To be honest, I find the mode 0 to be useless, but the spec is the spec :s -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 12 Dec '14

12 Dec '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #71 from Chernovsky Oleg <adonai(a)xaker.ru> --- Never mind last comment, just thought about additional registers in the middle of range. I'll have a SI part at the end of December, hope I'll be able to perform some tests on it. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 12 Dec '14

12 Dec '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #70 from Chernovsky Oleg <adonai(a)xaker.ru> --- (In reply to Alex Deucher from comment #69) > Yes they are at 0x75*, I just double checked the register database. Hmm ok... strange though, for CI the offset from CG_MULT_THERMAL_STATUS to CG_FDO_CTRL0 is 0x50, and from CG_FDO_CTRL0 to CG_TACH_CTRL is 0xC, but for SI they's 0x40 and (again!) 0xC accordingly... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 12 Dec '14

12 Dec '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #69 from Alex Deucher <alexdeucher(a)gmail.com> --- (In reply to Chernovsky Oleg from comment #67) > Alex, more comments, now on SI impl > > >#define CG_FDO_CTRL0 0x754 > >#define CG_FDO_CTRL1 0x758 > >#define CG_FDO_CTRL2 0x75C > > Are you sure they're 0x75* and not 0x76*? Yes they are at 0x75*, I just double checked the register database. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 12 Dec '14

12 Dec '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #68 from Chernovsky Oleg <adonai(a)xaker.ru> --- (In reply to Martin Peres from comment #66) Martin, there're things I think I didn't get correctly: - What should I return if pwm1_enable is 0 and I'm trying to push 50 into pwm1? - Can pwm1_enabled value be 2 after I push 0 to it? Radeon default fan value comes from fuse and it's not 100% -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel December 2014