[PATCH 1/2] tests/pm_rps: Round requested freq correctly

[PATCH 1/2] tests/pm_rps: Round requested freq correctly

[Daniel Vetter]

The kernel will round it, so if we don't we'll have a spurious
mismatch. Happens on my machine here with 650-1300MHz range, where the
midpoint is 975.

Cc: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 tests/pm_rps.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index 467038104ec6..27e758755e3f 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -350,6 +350,9 @@ static void min_max_config(void (*check)(void))
 {
 	int fmid = (origfreqs[RPn] + origfreqs[RP0]) / 2;
 
+	/* hw (and so kernel) currently rounds to 50 MHz ... */
+	fmid = fmid / 50 * 50;
+
 	log("\nCheck original min and max...\n");
 	check();
 
-- 
1.8.1.4

[PATCH 2/2] tests/pm_rps: remove setfreq

[Daniel Vetter]

It's unused.

Cc: Jeff McGee <jeff.mcgee@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
 tests/pm_rps.c | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/tests/pm_rps.c b/tests/pm_rps.c
index 27e758755e3f..3d374f92f82d 100644
--- a/tests/pm_rps.c
+++ b/tests/pm_rps.c
@@ -110,17 +110,6 @@ static int do_writeval(FILE *filp, int val, int lerrno)
 #define writeval(filp, val) do_writeval(filp, val, 0)
 #define writeval_inval(filp, val) do_writeval(filp, val, EINVAL)
 
-static void setfreq(int val)
-{
-	if (val > readval(stuff[MAX].filp)) {
-		writeval(stuff[MAX].filp, val);
-		writeval(stuff[MIN].filp, val);
-	} else {
-		writeval(stuff[MIN].filp, val);
-		writeval(stuff[MAX].filp, val);
-	}
-}
-
 static void checkit(const int *freqs)
 {
 	igt_assert(freqs[MIN] <= freqs[MAX]);
-- 
1.8.1.4

Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly

[Chris Wilson]

On Fri, Feb 07, 2014 at 10:03:33AM +0100, Daniel Vetter wrote:
> The kernel will round it, so if we don't we'll have a spurious
> mismatch. Happens on my machine here with 650-1300MHz range, where the
> midpoint is 975.
> 
> Cc: Jeff McGee <jeff.mcgee@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  tests/pm_rps.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> index 467038104ec6..27e758755e3f 100644
> --- a/tests/pm_rps.c
> +++ b/tests/pm_rps.c
> @@ -350,6 +350,9 @@ static void min_max_config(void (*check)(void))
>  {
>  	int fmid = (origfreqs[RPn] + origfreqs[RP0]) / 2;
>  
> +	/* hw (and so kernel) currently rounds to 50 MHz ... */

s/rounds/truncates/ or if it really does round, you need to adjust the
calculation.

> +	fmid = fmid / 50 * 50;
> +
>  	log("\nCheck original min and max...\n");
>  	check();
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly

[Daniel Vetter]

On Fri, Feb 7, 2014 at 10:33 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Fri, Feb 07, 2014 at 10:03:33AM +0100, Daniel Vetter wrote:
>> The kernel will round it, so if we don't we'll have a spurious
>> mismatch. Happens on my machine here with 650-1300MHz range, where the
>> midpoint is 975.
>>
>> Cc: Jeff McGee <jeff.mcgee@intel.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
>>  tests/pm_rps.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
>> index 467038104ec6..27e758755e3f 100644
>> --- a/tests/pm_rps.c
>> +++ b/tests/pm_rps.c
>> @@ -350,6 +350,9 @@ static void min_max_config(void (*check)(void))
>>  {
>>       int fmid = (origfreqs[RPn] + origfreqs[RP0]) / 2;
>>
>> +     /* hw (and so kernel) currently rounds to 50 MHz ... */
>
> s/rounds/truncates/ or if it really does round, you need to adjust the
> calculation.

We just need to use something divisible by 50 so that the value we
write and the one we get match up. Whether it's truncating or rounding
doesn't matter really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly

[Jeff McGee]

On Fri, Feb 07, 2014 at 11:15:15AM +0100, Daniel Vetter wrote:
> On Fri, Feb 7, 2014 at 10:33 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Fri, Feb 07, 2014 at 10:03:33AM +0100, Daniel Vetter wrote:
> >> The kernel will round it, so if we don't we'll have a spurious
> >> mismatch. Happens on my machine here with 650-1300MHz range, where the
> >> midpoint is 975.
> >>
> >> Cc: Jeff McGee <jeff.mcgee@intel.com>
> >> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> >> ---
> >>  tests/pm_rps.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> >> index 467038104ec6..27e758755e3f 100644
> >> --- a/tests/pm_rps.c
> >> +++ b/tests/pm_rps.c
> >> @@ -350,6 +350,9 @@ static void min_max_config(void (*check)(void))
> >>  {
> >>       int fmid = (origfreqs[RPn] + origfreqs[RP0]) / 2;
> >>
> >> +     /* hw (and so kernel) currently rounds to 50 MHz ... */
> >
> > s/rounds/truncates/ or if it really does round, you need to adjust the
> > calculation.
> 
> We just need to use something divisible by 50 so that the value we
> write and the one we get match up. Whether it's truncating or rounding
> doesn't matter really.
> -Daniel

Darn, I considered this possibility but forgot to account for it in the test.
I think what I was going to do was to create another writeval variant
which doesn't do read back matching check. This was because I didn't want to
assume that all systems use a 50 Mhz frequency increment (do they all?).
-Jeff

Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly

[Ville Syrjälä]

On Fri, Feb 07, 2014 at 08:44:14AM -0600, Jeff McGee wrote:
> On Fri, Feb 07, 2014 at 11:15:15AM +0100, Daniel Vetter wrote:
> > On Fri, Feb 7, 2014 at 10:33 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > On Fri, Feb 07, 2014 at 10:03:33AM +0100, Daniel Vetter wrote:
> > >> The kernel will round it, so if we don't we'll have a spurious
> > >> mismatch. Happens on my machine here with 650-1300MHz range, where the
> > >> midpoint is 975.
> > >>
> > >> Cc: Jeff McGee <jeff.mcgee@intel.com>
> > >> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > >> ---
> > >>  tests/pm_rps.c | 3 +++
> > >>  1 file changed, 3 insertions(+)
> > >>
> > >> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> > >> index 467038104ec6..27e758755e3f 100644
> > >> --- a/tests/pm_rps.c
> > >> +++ b/tests/pm_rps.c
> > >> @@ -350,6 +350,9 @@ static void min_max_config(void (*check)(void))
> > >>  {
> > >>       int fmid = (origfreqs[RPn] + origfreqs[RP0]) / 2;
> > >>
> > >> +     /* hw (and so kernel) currently rounds to 50 MHz ... */
> > >
> > > s/rounds/truncates/ or if it really does round, you need to adjust the
> > > calculation.
> > 
> > We just need to use something divisible by 50 so that the value we
> > write and the one we get match up. Whether it's truncating or rounding
> > doesn't matter really.
> > -Daniel
> 
> Darn, I considered this possibility but forgot to account for it in the test.
> I think what I was going to do was to create another writeval variant
> which doesn't do read back matching check. This was because I didn't want to
> assume that all systems use a 50 Mhz frequency increment (do they all?).

VLV sure doesn't.

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly

[Daniel Vetter]

On Fri, Feb 07, 2014 at 04:52:30PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 07, 2014 at 08:44:14AM -0600, Jeff McGee wrote:
> > On Fri, Feb 07, 2014 at 11:15:15AM +0100, Daniel Vetter wrote:
> > > On Fri, Feb 7, 2014 at 10:33 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > > > On Fri, Feb 07, 2014 at 10:03:33AM +0100, Daniel Vetter wrote:
> > > >> The kernel will round it, so if we don't we'll have a spurious
> > > >> mismatch. Happens on my machine here with 650-1300MHz range, where the
> > > >> midpoint is 975.
> > > >>
> > > >> Cc: Jeff McGee <jeff.mcgee@intel.com>
> > > >> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > >> ---
> > > >>  tests/pm_rps.c | 3 +++
> > > >>  1 file changed, 3 insertions(+)
> > > >>
> > > >> diff --git a/tests/pm_rps.c b/tests/pm_rps.c
> > > >> index 467038104ec6..27e758755e3f 100644
> > > >> --- a/tests/pm_rps.c
> > > >> +++ b/tests/pm_rps.c
> > > >> @@ -350,6 +350,9 @@ static void min_max_config(void (*check)(void))
> > > >>  {
> > > >>       int fmid = (origfreqs[RPn] + origfreqs[RP0]) / 2;
> > > >>
> > > >> +     /* hw (and so kernel) currently rounds to 50 MHz ... */
> > > >
> > > > s/rounds/truncates/ or if it really does round, you need to adjust the
> > > > calculation.
> > > 
> > > We just need to use something divisible by 50 so that the value we
> > > write and the one we get match up. Whether it's truncating or rounding
> > > doesn't matter really.
> > > -Daniel
> > 
> > Darn, I considered this possibility but forgot to account for it in the test.
> > I think what I was going to do was to create another writeval variant
> > which doesn't do read back matching check. This was because I didn't want to
> > assume that all systems use a 50 Mhz frequency increment (do they all?).
> 
> VLV sure doesn't.

Well I've hacked around it for now. But I agree that an unchecked
write-val for fmid would be the better approach.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch