Message ID | 1311715739-3551-1-git-send-email-j.glisse@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Tue, Jul 26, 2011 at 5:28 PM, <j.glisse@gmail.com> wrote: > From: Jerome Glisse <jglisse@redhat.com> > > Some CP interrupt were left enabled when disabling interrupt. > Is there a specific issue this fixes? The bits are not interrupt sources per se but rather are related to the internal state of the interrupt controller and should always be enabled. Alex > Signed-off-by: Jerome Glisse <jglisse@redhat.com> > --- > drivers/gpu/drm/radeon/evergreen.c | 2 +- > drivers/gpu/drm/radeon/r600.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c > index 14dce9f..852565d 100644 > --- a/drivers/gpu/drm/radeon/evergreen.c > +++ b/drivers/gpu/drm/radeon/evergreen.c > @@ -2434,7 +2434,7 @@ void evergreen_disable_interrupt_state(struct radeon_device *rdev) > { > u32 tmp; > > - WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE); > + WREG32(CP_INT_CNTL, 0); > WREG32(GRBM_INT_CNTL, 0); > WREG32(INT_MASK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0); > WREG32(INT_MASK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0); > diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c > index aa5571b..d2c74e7 100644 > --- a/drivers/gpu/drm/radeon/r600.c > +++ b/drivers/gpu/drm/radeon/r600.c > @@ -2900,7 +2900,7 @@ static void r600_disable_interrupt_state(struct radeon_device *rdev) > { > u32 tmp; > > - WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE); > + WREG32(CP_INT_CNTL, 0); > WREG32(GRBM_INT_CNTL, 0); > WREG32(DxMODE_INT_MASK, 0); > WREG32(D1GRPH_INTERRUPT_CONTROL, 0); > -- > 1.7.3.2 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher <alexdeucher@gmail.com> wrote: > On Tue, Jul 26, 2011 at 5:28 PM, <j.glisse@gmail.com> wrote: >> From: Jerome Glisse <jglisse@redhat.com> >> >> Some CP interrupt were left enabled when disabling interrupt. >> > > Is there a specific issue this fixes? The bits are not interrupt > sources per se but rather are related to the internal state of the > interrupt controller and should always be enabled. > > Alex > Might, might not i have seen flgrx unsetting this bit on my rv670 which reboot with the radeon driver. Jerome
On Tue, Jul 26, 2011 at 7:43 PM, Jerome Glisse <j.glisse@gmail.com> wrote: > On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher <alexdeucher@gmail.com> wrote: >> On Tue, Jul 26, 2011 at 5:28 PM, <j.glisse@gmail.com> wrote: >>> From: Jerome Glisse <jglisse@redhat.com> >>> >>> Some CP interrupt were left enabled when disabling interrupt. >>> >> >> Is there a specific issue this fixes? The bits are not interrupt >> sources per se but rather are related to the internal state of the >> interrupt controller and should always be enabled. >> >> Alex >> > > Might, might not i have seen flgrx unsetting this bit on my rv670 > which reboot with the radeon driver. Have you narrowed down what part of init is causing the problem? I used to have a drm noaccel patch that disabled CP, GART, interrupts, etc. Alex
On Wed, Jul 27, 2011 at 11:30 AM, Alex Deucher <alexdeucher@gmail.com> wrote: > On Tue, Jul 26, 2011 at 7:43 PM, Jerome Glisse <j.glisse@gmail.com> wrote: >> On Tue, Jul 26, 2011 at 5:47 PM, Alex Deucher <alexdeucher@gmail.com> wrote: >>> On Tue, Jul 26, 2011 at 5:28 PM, <j.glisse@gmail.com> wrote: >>>> From: Jerome Glisse <jglisse@redhat.com> >>>> >>>> Some CP interrupt were left enabled when disabling interrupt. >>>> >>> >>> Is there a specific issue this fixes? The bits are not interrupt >>> sources per se but rather are related to the internal state of the >>> interrupt controller and should always be enabled. >>> >>> Alex >>> >> >> Might, might not i have seen flgrx unsetting this bit on my rv670 >> which reboot with the radeon driver. > > Have you narrowed down what part of init is causing the problem? I > used to have a drm noaccel patch that disabled CP, GART, interrupts, > etc. > > Alex > It happens early after mc programing from r600_startup after that pretty much any reg write (no matter what reg) will trigger the computer reset. Cheers, Jerome
diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index 14dce9f..852565d 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -2434,7 +2434,7 @@ void evergreen_disable_interrupt_state(struct radeon_device *rdev) { u32 tmp; - WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE); + WREG32(CP_INT_CNTL, 0); WREG32(GRBM_INT_CNTL, 0); WREG32(INT_MASK + EVERGREEN_CRTC0_REGISTER_OFFSET, 0); WREG32(INT_MASK + EVERGREEN_CRTC1_REGISTER_OFFSET, 0); diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index aa5571b..d2c74e7 100644 --- a/drivers/gpu/drm/radeon/r600.c +++ b/drivers/gpu/drm/radeon/r600.c @@ -2900,7 +2900,7 @@ static void r600_disable_interrupt_state(struct radeon_device *rdev) { u32 tmp; - WREG32(CP_INT_CNTL, CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE); + WREG32(CP_INT_CNTL, 0); WREG32(GRBM_INT_CNTL, 0); WREG32(DxMODE_INT_MASK, 0); WREG32(D1GRPH_INTERRUPT_CONTROL, 0);