Am 25.07.2014 um 05:05 schrieb Alex Deucher:
On Thu, Jul 24, 2014 at 10:24 PM, Michel Dänzer <michel@xxxxxxxxxxx> wrote:
On 25.07.2014 11:06, Michel Dänzer wrote:
On 25.07.2014 11:05, Michel Dänzer wrote:
On 25.07.2014 08:51, Alex Deucher wrote:
We need to make sure we have a new enough firmware with
the fixed nop packet.
Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx>
---
drivers/gpu/drm/radeon/radeon_kms.c | 6 ++++++
include/uapi/drm/radeon_drm.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c
index 35d9318..3ea9f59 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -529,6 +529,12 @@ static int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file
else
*value = 1;
break;
+ case RADEON_INFO_HAWAII_ACCEL:
+ if (rdev->new_fw)
+ *value = 1;
+ else
+ *value = 0;
+ break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 509b2d7..a41dec3 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -1010,6 +1010,7 @@ struct drm_radeon_cs {
#define RADEON_INFO_VRAM_USAGE 0x1e
#define RADEON_INFO_GTT_USAGE 0x1f
#define RADEON_INFO_ACTIVE_CU_COUNT 0x20
+#define RADEON_INFO_HAWAII_ACCEL 0x21
struct drm_radeon_info {
uint32_t request;
Please make the RADEON_INFO_ACCEL_WORKING(2) ioctl do the right thing
for Hawaii instead of adding yet another one.
Ugh, s/ioctl/info query/ of course.
Hmm, I guess that doesn't work because older kernels returned 1 for
those on Hawaii...
Right. The hawaii problems came down to two things:
1. missing tiling info setup (fixed with Jerome's patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.17-wip&id=78e758aa27d9d430c61999160ddf72e829c5cf26)
for hawaii. This was due to merging hawaii support after we fixed up
CI tiling. Dave already merged this and it should show up in stable.
2. The current Hawaii CP firmware doesn't support the special case
0xffff1000 type 3 NOP packet. The newer firmware version I added
support for in 3.17 supports this packet.
So we can either patch mesa to use the type 2 packets for now and
allow it to work with kernels with older firmware. The problem is the
compute rings don't support type 2 packets anymore and they are
deprecated on gfx, plus we'd still have to deal with existing versions
of mesa that still use the problematic packet.
It just seemed easier to add a new kernel check.
Can we still make the check a bit more generic? E.g. not so HAWAII
specific name and maybe returning more information from the new firmware
header?
Something like this,
Christian.
Alex
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
