| Message ID | 1406245907-2567-2-git-send-email-alexander.deucher@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@amd.com> > --- > 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.
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@amd.com> >> --- >> 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.
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@amd.com> >>> --- >>> 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...
On Thu, Jul 24, 2014 at 10:24 PM, Michel Dänzer <michel@daenzer.net> 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@amd.com> >>>> --- >>>> 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. Alex
Am 25.07.2014 um 05:05 schrieb Alex Deucher: > On Thu, Jul 24, 2014 at 10:24 PM, Michel Dänzer <michel@daenzer.net> 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@amd.com> >>>>> --- >>>>> 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jul 25, 2014 at 11:30:55AM +0200, Christian König wrote: > Am 25.07.2014 um 05:05 schrieb Alex Deucher: > >On Thu, Jul 24, 2014 at 10:24 PM, Michel Dänzer <michel@daenzer.net> 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@amd.com> > >>>>>--- > >>>>> 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. I would rather not add anything, let just dump drm version in 3.17 and use that to enable compute and in mean time disable compute for hawaii but enable gfx if we detect 3.16. This would be a lot cleaner and no need for yet another get_info ie we make 3.17 only report accel if new firmware is detected. Cheers, Jérôme
Can't we just make the accel2 info return 2 instead of 1? and have userspace know the difference. be careful to make userspace work so we can return 3 in future. Dave.
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;
We need to make sure we have a new enough firmware with the fixed nop packet. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> --- drivers/gpu/drm/radeon/radeon_kms.c | 6 ++++++ include/uapi/drm/radeon_drm.h | 1 + 2 files changed, 7 insertions(+)