diff mbox

Mobility Radeon HD 4530/4570/545v: flicker in 1920x1080

Message ID 20151104221000.GA3608@amd (mailing list archive)
State New, archived
Headers show

Commit Message

Pavel Machek Nov. 4, 2015, 10:10 p.m. UTC
Hi!

> >>>>index dac78ad..b86f06a 100644
> >>>>--- a/drivers/gpu/drm/radeon/atombios_crtc.c
> >>>>+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> >>>>@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
> >>>>         radeon_crtc->pll_flags = 0;
> >>>>
> >>>>         if (ASIC_IS_AVIVO(rdev)) {
> >>>>+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
> >>>>+
> >>>>                 if ((rdev->family == CHIP_RS600) ||
> >>>>                     (rdev->family == CHIP_RS690) ||
> >>>>                     (rdev->family == CHIP_RS740))
> >>>>
> >>>Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
> >>>issue completely.
> >>You could also try the old pll algorithm:
> >I reverted the patch above, and switched to the old algorithm.
> >
> >The flicker is still there. (But maybe its less horrible, like with
> >RADEON_PLL_PREFER_MINM_OVER_MAXP).
> 
> The flickering would vanish completely if that's the reason for the issue
> you are seeing.

> Try setting ref_div_min and ref_div_max to 2 in
>  radeon_compute_pll_avivo().

Ok, I did this, but no luck, still flickers. But the flicker only
happens when something changes on screen, like dragging a big
window. Is that consistent with wrong PLL timings?



> But I'm not 100% convinced that this is actually a PLL problem, try to
> compile the firmware it complains about into the kernel as well.

Did that, too.

Best regards,
									Pavel

Comments

Alex Deucher Nov. 4, 2015, 10:13 p.m. UTC | #1
On Wed, Nov 4, 2015 at 5:10 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >>>>index dac78ad..b86f06a 100644
>> >>>>--- a/drivers/gpu/drm/radeon/atombios_crtc.c
>> >>>>+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>> >>>>@@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>> >>>>         radeon_crtc->pll_flags = 0;
>> >>>>
>> >>>>         if (ASIC_IS_AVIVO(rdev)) {
>> >>>>+               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>> >>>>+
>> >>>>                 if ((rdev->family == CHIP_RS600) ||
>> >>>>                     (rdev->family == CHIP_RS690) ||
>> >>>>                     (rdev->family == CHIP_RS740))
>> >>>>
>> >>>Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
>> >>>issue completely.
>> >>You could also try the old pll algorithm:
>> >I reverted the patch above, and switched to the old algorithm.
>> >
>> >The flicker is still there. (But maybe its less horrible, like with
>> >RADEON_PLL_PREFER_MINM_OVER_MAXP).
>>
>> The flickering would vanish completely if that's the reason for the issue
>> you are seeing.
>
>> Try setting ref_div_min and ref_div_max to 2 in
>>  radeon_compute_pll_avivo().
>
> Ok, I did this, but no luck, still flickers. But the flicker only
> happens when something changes on screen, like dragging a big
> window. Is that consistent with wrong PLL timings?

Does it go away with radeon.dpm=0?  Sounds more like either memory
reclocking happening outside of vblank, or underflow to the display
controllers.

Alex

>
> diff --git a/config.32 b/config.32
> index 00e5dd2..4734158 100644
> --- a/config.32
> +++ b/config.32
> @@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
>  CONFIG_PREVENT_FIRMWARE_BUILD=y
>  CONFIG_FW_LOADER=y
>  CONFIG_FIRMWARE_IN_KERNEL=y
> -CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
> +CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
>  CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>  # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
>  CONFIG_ALLOW_DEV_COREDUMP=y
> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
> index dac78ad..dcc4f4d 100644
> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>         radeon_crtc->pll_flags = 0;
>
>         if (ASIC_IS_AVIVO(rdev)) {
> +               //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
> +
>                 if ((rdev->family == CHIP_RS600) ||
>                     (rdev->family == CHIP_RS690) ||
>                     (rdev->family == CHIP_RS740))
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
> index 6743174..bebaf4f 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>         fb_div_max = pll->max_feedback_div;
>
>         if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
> +               printk("radeon: fractional divider\n");
>                 fb_div_min *= 10;
>                 fb_div_max *= 10;
>         }
> @@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>         else
>                 ref_div_max = pll->max_ref_div;
>
> +       ref_div_min = 2;
> +       ref_div_max = 2;
> +
>         /* determine allowed post divider range */
>         if (pll->flags & RADEON_PLL_USE_POST_DIV) {
>                 post_div_min = pll->post_div;
> @@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>                 diff = abs(target_clock - (pll->reference_freq * fb_div) /
>                         (ref_div * post_div));
>
> +               printk("post_div = %d, diff = %d\n", post_div, diff);
> +
>                 if (diff < diff_best || (diff == diff_best &&
>                     !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
>
> @@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>                 }
>         }
>         post_div = post_div_best;
> +       printk("Selected post_div = %d\n", post_div);
>
>         /* get the feedback and reference divider for the optimal value */
>         avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,
> @@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>         *ref_div_p = ref_div;
>         *post_div_p = post_div;
>
> -       DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
> +       printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
>                       freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
>                       ref_div, post_div);
>  }
>
>
>> But I'm not 100% convinced that this is actually a PLL problem, try to
>> compile the firmware it complains about into the kernel as well.
>
> Did that, too.
>
> Best regards,
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Christian König Nov. 5, 2015, 10:43 a.m. UTC | #2
On 04.11.2015 23:13, Alex Deucher wrote:
> On Wed, Nov 4, 2015 at 5:10 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>>>>>>> index dac78ad..b86f06a 100644
>>>>>>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>>>>>>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>>>>>>> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>>>>>>>          radeon_crtc->pll_flags = 0;
>>>>>>>
>>>>>>>          if (ASIC_IS_AVIVO(rdev)) {
>>>>>>> +               radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>>>>>>> +
>>>>>>>                  if ((rdev->family == CHIP_RS600) ||
>>>>>>>                      (rdev->family == CHIP_RS690) ||
>>>>>>>                      (rdev->family == CHIP_RS740))
>>>>>>>
>>>>>> Help.. maybe... it is tricky to tell. It definitely does _not_ fix the
>>>>>> issue completely.
>>>>> You could also try the old pll algorithm:
>>>> I reverted the patch above, and switched to the old algorithm.
>>>>
>>>> The flicker is still there. (But maybe its less horrible, like with
>>>> RADEON_PLL_PREFER_MINM_OVER_MAXP).
>>> The flickering would vanish completely if that's the reason for the issue
>>> you are seeing.
>>> Try setting ref_div_min and ref_div_max to 2 in
>>>   radeon_compute_pll_avivo().
>> Ok, I did this, but no luck, still flickers. But the flicker only
>> happens when something changes on screen, like dragging a big
>> window. Is that consistent with wrong PLL timings?
> Does it go away with radeon.dpm=0?  Sounds more like either memory
> reclocking happening outside of vblank, or underflow to the display
> controllers.

Sounds like my suspicion was right, that doesn't seem to be a PLL issue 
after all.

Just to rule out the obvious your system works fine with windows and you 
don't have a extra long cable for the monitor or something like this?

Regards,
Christian.

>
> Alex
>
>> diff --git a/config.32 b/config.32
>> index 00e5dd2..4734158 100644
>> --- a/config.32
>> +++ b/config.32
>> @@ -1090,7 +1090,7 @@ CONFIG_DEVTMPFS_MOUNT=y
>>   CONFIG_PREVENT_FIRMWARE_BUILD=y
>>   CONFIG_FW_LOADER=y
>>   CONFIG_FIRMWARE_IN_KERNEL=y
>> -CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
>> +CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
>>   CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
>>   # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
>>   CONFIG_ALLOW_DEV_COREDUMP=y
>> diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
>> index dac78ad..dcc4f4d 100644
>> --- a/drivers/gpu/drm/radeon/atombios_crtc.c
>> +++ b/drivers/gpu/drm/radeon/atombios_crtc.c
>> @@ -569,6 +569,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc,
>>          radeon_crtc->pll_flags = 0;
>>
>>          if (ASIC_IS_AVIVO(rdev)) {
>> +               //radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
>> +
>>                  if ((rdev->family == CHIP_RS600) ||
>>                      (rdev->family == CHIP_RS690) ||
>>                      (rdev->family == CHIP_RS740))
>> diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
>> index 6743174..bebaf4f 100644
>> --- a/drivers/gpu/drm/radeon/radeon_display.c
>> +++ b/drivers/gpu/drm/radeon/radeon_display.c
>> @@ -947,6 +947,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>          fb_div_max = pll->max_feedback_div;
>>
>>          if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
>> +               printk("radeon: fractional divider\n");
>>                  fb_div_min *= 10;
>>                  fb_div_max *= 10;
>>          }
>> @@ -966,6 +967,9 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>          else
>>                  ref_div_max = pll->max_ref_div;
>>
>> +       ref_div_min = 2;
>> +       ref_div_max = 2;
>> +
>>          /* determine allowed post divider range */
>>          if (pll->flags & RADEON_PLL_USE_POST_DIV) {
>>                  post_div_min = pll->post_div;
>> @@ -1020,6 +1024,8 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>                  diff = abs(target_clock - (pll->reference_freq * fb_div) /
>>                          (ref_div * post_div));
>>
>> +               printk("post_div = %d, diff = %d\n", post_div, diff);
>> +
>>                  if (diff < diff_best || (diff == diff_best &&
>>                      !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
>>
>> @@ -1028,6 +1034,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>                  }
>>          }
>>          post_div = post_div_best;
>> +       printk("Selected post_div = %d\n", post_div);
>>
>>          /* get the feedback and reference divider for the optimal value */
>>          avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,
>> @@ -1062,7 +1069,7 @@ void radeon_compute_pll_avivo(struct radeon_pll *pll,
>>          *ref_div_p = ref_div;
>>          *post_div_p = post_div;
>>
>> -       DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
>> +       printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
>>                        freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
>>                        ref_div, post_div);
>>   }
>>
>>
>>> But I'm not 100% convinced that this is actually a PLL problem, try to
>>> compile the firmware it complains about into the kernel as well.
>> Did that, too.
>>
>> Best regards,
>>                                                                          Pavel
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek Nov. 5, 2015, 8:23 p.m. UTC | #3
Hi!

> >> The flickering would vanish completely if that's the reason for the issue
> >> you are seeing.
> >
> >> Try setting ref_div_min and ref_div_max to 2 in
> >>  radeon_compute_pll_avivo().
> >
> > Ok, I did this, but no luck, still flickers. But the flicker only
> > happens when something changes on screen, like dragging a big
> > window. Is that consistent with wrong PLL timings?
> 
> Does it go away with radeon.dpm=0?  Sounds more like either memory
> reclocking happening outside of vblank, or underflow to the display
> controllers.

No, it does not:

pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0

..and same issue. And yes, it looks like an underflow to me. How can I
debug reclocking / underflows?

Best regards,
									Pavel
Pavel Machek Nov. 5, 2015, 8:26 p.m. UTC | #4
> >>>>RADEON_PLL_PREFER_MINM_OVER_MAXP).
> >>>The flickering would vanish completely if that's the reason for the issue
> >>>you are seeing.
> >>>Try setting ref_div_min and ref_div_max to 2 in
> >>>  radeon_compute_pll_avivo().
> >>Ok, I did this, but no luck, still flickers. But the flicker only
> >>happens when something changes on screen, like dragging a big
> >>window. Is that consistent with wrong PLL timings?
> >Does it go away with radeon.dpm=0?  Sounds more like either memory
> >reclocking happening outside of vblank, or underflow to the display
> >controllers.
> 
> Sounds like my suspicion was right, that doesn't seem to be a PLL issue
> after all.
> 
> Just to rule out the obvious your system works fine with windows and you
> don't have a extra long cable for the monitor or something like
>this?

Cable is something like 2 meters. It does not seem to be EMI, because
it only happens when the display is being updated.

The system had some thermal issues before, but a) there's big fan
cooling it now and b) it does not get worse with more usage. I don't
think its heat.

I don't have Windows for a test, sorry.

Best regards,
									Pavel
Michel Dänzer Nov. 6, 2015, 2:25 a.m. UTC | #5
On 06.11.2015 05:23, Pavel Machek wrote:
> Hi!
> 
>>>> The flickering would vanish completely if that's the reason for the issue
>>>> you are seeing.
>>>
>>>> Try setting ref_div_min and ref_div_max to 2 in
>>>>  radeon_compute_pll_avivo().
>>>
>>> Ok, I did this, but no luck, still flickers. But the flicker only
>>> happens when something changes on screen, like dragging a big
>>> window. Is that consistent with wrong PLL timings?
>>
>> Does it go away with radeon.dpm=0?  Sounds more like either memory
>> reclocking happening outside of vblank, or underflow to the display
>> controllers.
> 
> No, it does not:
> 
> pavel@half:~$ cat /proc/cmdline
> BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
> resume=/dev/sda1 radeon.dpm=0
> 
> ..and same issue. And yes, it looks like an underflow to me. How can I
> debug reclocking / underflows?

Does radeon.disp_priority=2 help?
Pavel Machek Nov. 6, 2015, 12:45 p.m. UTC | #6
On Fri 2015-11-06 11:25:09, Michel Dänzer wrote:
> On 06.11.2015 05:23, Pavel Machek wrote:
> > Hi!
> > 
> >>>> The flickering would vanish completely if that's the reason for the issue
> >>>> you are seeing.
> >>>
> >>>> Try setting ref_div_min and ref_div_max to 2 in
> >>>>  radeon_compute_pll_avivo().
> >>>
> >>> Ok, I did this, but no luck, still flickers. But the flicker only
> >>> happens when something changes on screen, like dragging a big
> >>> window. Is that consistent with wrong PLL timings?
> >>
> >> Does it go away with radeon.dpm=0?  Sounds more like either memory
> >> reclocking happening outside of vblank, or underflow to the display
> >> controllers.
> > 
> > No, it does not:
> > 
> > pavel@half:~$ cat /proc/cmdline
> > BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
> > resume=/dev/sda1 radeon.dpm=0
> > 
> > ..and same issue. And yes, it looks like an underflow to me. How can I
> > debug reclocking / underflows?
> 
> Does radeon.disp_priority=2 help?

Tried this, and no change, still flickers.

pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0 radeon.disp_priority=2
pavel@half:~$

I searched for some more config options, and tried:

pavel@half:~$ cat /proc/cmdline
BOOT_IMAGE=(hd0,2)/l/linux/arch/x86/boot/bzImage root=/dev/sda4
resume=/dev/sda1 radeon.dpm=0 radeon.disp_priority=2
radeon.amdgpu_runtime_pm=0 radeon.bapm=0 radeon.sched_hw_submission=0
radeon.enable_semaphores=0
pavel@half:~$

..still flickers.

Best regards,
									Pavel
diff mbox

Patch

diff --git a/config.32 b/config.32
index 00e5dd2..4734158 100644
--- a/config.32
+++ b/config.32
@@ -1090,7 +1090,7 @@  CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 CONFIG_FW_LOADER=y
 CONFIG_FIRMWARE_IN_KERNEL=y
-CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin"
+CONFIG_EXTRA_FIRMWARE="radeon/R700_rlc.bin radeon/RV710_smc.bin radeon/RV710_uvd.bin"
 CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
 # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set
 CONFIG_ALLOW_DEV_COREDUMP=y
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index dac78ad..dcc4f4d 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -569,6 +569,8 @@  static u32 atombios_adjust_pll(struct drm_crtc *crtc,
 	radeon_crtc->pll_flags = 0;
 
 	if (ASIC_IS_AVIVO(rdev)) {
+		//radeon_crtc->pll_flags |= RADEON_PLL_PREFER_MINM_OVER_MAXP;
+
 		if ((rdev->family == CHIP_RS600) ||
 		    (rdev->family == CHIP_RS690) ||
 		    (rdev->family == CHIP_RS740))
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index 6743174..bebaf4f 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -947,6 +947,7 @@  void radeon_compute_pll_avivo(struct radeon_pll *pll,
 	fb_div_max = pll->max_feedback_div;
 
 	if (pll->flags & RADEON_PLL_USE_FRAC_FB_DIV) {
+		printk("radeon: fractional divider\n");
 		fb_div_min *= 10;
 		fb_div_max *= 10;
 	}
@@ -966,6 +967,9 @@  void radeon_compute_pll_avivo(struct radeon_pll *pll,
 	else
 		ref_div_max = pll->max_ref_div;
 
+	ref_div_min = 2;
+	ref_div_max = 2;
+
 	/* determine allowed post divider range */
 	if (pll->flags & RADEON_PLL_USE_POST_DIV) {
 		post_div_min = pll->post_div;
@@ -1020,6 +1024,8 @@  void radeon_compute_pll_avivo(struct radeon_pll *pll,
 		diff = abs(target_clock - (pll->reference_freq * fb_div) /
 			(ref_div * post_div));
 
+		printk("post_div = %d, diff = %d\n", post_div, diff);
+
 		if (diff < diff_best || (diff == diff_best &&
 		    !(pll->flags & RADEON_PLL_PREFER_MINM_OVER_MAXP))) {
 
@@ -1028,6 +1034,7 @@  void radeon_compute_pll_avivo(struct radeon_pll *pll,
 		}
 	}
 	post_div = post_div_best;
+	printk("Selected post_div = %d\n", post_div);
 
 	/* get the feedback and reference divider for the optimal value */
 	avivo_get_fb_ref_div(nom, den, post_div, fb_div_max, ref_div_max,
@@ -1062,7 +1069,7 @@  void radeon_compute_pll_avivo(struct radeon_pll *pll,
 	*ref_div_p = ref_div;
 	*post_div_p = post_div;
 
-	DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
+	printk("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
 		      freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
 		      ref_div, post_div);
 }