* [PATCH 1/2] tests/pm_rps: Round requested freq correctly @ 2014-02-07 9:03 Daniel Vetter 2014-02-07 9:03 ` [PATCH 2/2] tests/pm_rps: remove setfreq Daniel Vetter 2014-02-07 9:33 ` [PATCH 1/2] tests/pm_rps: Round requested freq correctly Chris Wilson 0 siblings, 2 replies; 7+ messages in thread From: Daniel Vetter @ 2014-02-07 9:03 UTC (permalink / raw) To: Intel Graphics Development; +Cc: 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* [PATCH 2/2] tests/pm_rps: remove setfreq 2014-02-07 9:03 [PATCH 1/2] tests/pm_rps: Round requested freq correctly Daniel Vetter @ 2014-02-07 9:03 ` Daniel Vetter 2014-02-07 9:33 ` [PATCH 1/2] tests/pm_rps: Round requested freq correctly Chris Wilson 1 sibling, 0 replies; 7+ messages in thread From: Daniel Vetter @ 2014-02-07 9:03 UTC (permalink / raw) To: Intel Graphics Development; +Cc: 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly 2014-02-07 9:03 [PATCH 1/2] tests/pm_rps: Round requested freq correctly Daniel Vetter 2014-02-07 9:03 ` [PATCH 2/2] tests/pm_rps: remove setfreq Daniel Vetter @ 2014-02-07 9:33 ` Chris Wilson 2014-02-07 10:15 ` Daniel Vetter 1 sibling, 1 reply; 7+ messages in thread From: Chris Wilson @ 2014-02-07 9:33 UTC (permalink / raw) To: Daniel Vetter; +Cc: Intel Graphics Development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly 2014-02-07 9:33 ` [PATCH 1/2] tests/pm_rps: Round requested freq correctly Chris Wilson @ 2014-02-07 10:15 ` Daniel Vetter 2014-02-07 14:44 ` Jeff McGee 0 siblings, 1 reply; 7+ messages in thread From: Daniel Vetter @ 2014-02-07 10:15 UTC (permalink / raw) To: Chris Wilson, Daniel Vetter, Intel Graphics Development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly 2014-02-07 10:15 ` Daniel Vetter @ 2014-02-07 14:44 ` Jeff McGee 2014-02-07 14:52 ` Ville Syrjälä 0 siblings, 1 reply; 7+ messages in thread From: Jeff McGee @ 2014-02-07 14:44 UTC (permalink / raw) To: Daniel Vetter; +Cc: Intel Graphics Development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly 2014-02-07 14:44 ` Jeff McGee @ 2014-02-07 14:52 ` Ville Syrjälä 2014-02-07 15:08 ` Daniel Vetter 0 siblings, 1 reply; 7+ messages in thread From: Ville Syrjälä @ 2014-02-07 14:52 UTC (permalink / raw) To: Daniel Vetter, Chris Wilson, Intel Graphics Development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] tests/pm_rps: Round requested freq correctly 2014-02-07 14:52 ` Ville Syrjälä @ 2014-02-07 15:08 ` Daniel Vetter 0 siblings, 0 replies; 7+ messages in thread From: Daniel Vetter @ 2014-02-07 15:08 UTC (permalink / raw) To: Ville Syrjälä; +Cc: Daniel Vetter, Intel Graphics Development 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-02-07 15:09 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-07 9:03 [PATCH 1/2] tests/pm_rps: Round requested freq correctly Daniel Vetter 2014-02-07 9:03 ` [PATCH 2/2] tests/pm_rps: remove setfreq Daniel Vetter 2014-02-07 9:33 ` [PATCH 1/2] tests/pm_rps: Round requested freq correctly Chris Wilson 2014-02-07 10:15 ` Daniel Vetter 2014-02-07 14:44 ` Jeff McGee 2014-02-07 14:52 ` Ville Syrjälä 2014-02-07 15:08 ` Daniel Vetter
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.