Message ID | 1436183051-27263-1-git-send-email-ville.syrjala@linux.intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On 7/6/2015 5:14 PM, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Since > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > Author: Vandana Kannan <vandana.kannan@intel.com> > Date: Wed Jul 1 17:02:57 2015 +0530 > > drm/i915/bxt: BUNs related to port PLL > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > Adjust the HDMI port clock checks to account for the reduced range > of invalid frequencies. > > Cc: Vandana Kannan <vandana.kannan@intel.com> > Cc: Imre Deak <imre.deak@intel.com> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > drivers/gpu/drm/i915/intel_hdmi.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c > index c7e912b..70bad5b 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1174,9 +1174,12 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi, > if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit)) > return MODE_CLOCK_HIGH; > > - /* CHV/BXT DPLL can't generate 216-240 MHz */ > - if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) && > - clock > 216000 && clock < 240000) > + /* BXT DPLL can't generate 223-240 MHz */ > + if (IS_BROXTON(dev) && clock > 223333 && clock < 240000) > + return MODE_CLOCK_RANGE; > + BSpec needs an update based on this ? It shows " HDMI/DVI link rates: 0.2 to 3.0 GHz Non-SSC* *2.17 - 2.4 GHz not supported " - Vandana > + /* CHV DPLL can't generate 216-240 MHz */ > + if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000) > return MODE_CLOCK_RANGE; > > return MODE_OK; >
On ma, 2015-07-06 at 14:44 +0300, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Since > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > Author: Vandana Kannan <vandana.kannan@intel.com> > Date: Wed Jul 1 17:02:57 2015 +0530 > > drm/i915/bxt: BUNs related to port PLL > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > Adjust the HDMI port clock checks to account for the reduced range > of invalid frequencies. > > Cc: Vandana Kannan <vandana.kannan@intel.com> > Cc: Imre Deak <imre.deak@intel.com> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Ville wrote a tool for CHV that calculates the valid frequencies based on the algorithm in the kernel. With the help of that I verified that this matches the list of target frequencies bxt_find_best_dpll() will accept, so: Reviewed-by: Imre Deak <imre.deak@intel.com> > --- > drivers/gpu/drm/i915/intel_hdmi.c | 9 ++++++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c > index c7e912b..70bad5b 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1174,9 +1174,12 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi, > if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit)) > return MODE_CLOCK_HIGH; > > - /* CHV/BXT DPLL can't generate 216-240 MHz */ > - if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) && > - clock > 216000 && clock < 240000) > + /* BXT DPLL can't generate 223-240 MHz */ > + if (IS_BROXTON(dev) && clock > 223333 && clock < 240000) > + return MODE_CLOCK_RANGE; > + > + /* CHV DPLL can't generate 216-240 MHz */ > + if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000) > return MODE_CLOCK_RANGE; > > return MODE_OK;
On ke, 2015-07-08 at 15:07 +0530, Kannan, Vandana wrote: > > On 7/6/2015 5:14 PM, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Since > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > Author: Vandana Kannan <vandana.kannan@intel.com> > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > drm/i915/bxt: BUNs related to port PLL > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > Adjust the HDMI port clock checks to account for the reduced range > > of invalid frequencies. > > > > Cc: Vandana Kannan <vandana.kannan@intel.com> > > Cc: Imre Deak <imre.deak@intel.com> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > --- > > drivers/gpu/drm/i915/intel_hdmi.c | 9 ++++++--- > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c > > index c7e912b..70bad5b 100644 > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > @@ -1174,9 +1174,12 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi, > > if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit)) > > return MODE_CLOCK_HIGH; > > > > - /* CHV/BXT DPLL can't generate 216-240 MHz */ > > - if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) && > > - clock > 216000 && clock < 240000) > > + /* BXT DPLL can't generate 223-240 MHz */ > > + if (IS_BROXTON(dev) && clock > 223333 && clock < 240000) > > + return MODE_CLOCK_RANGE; > > + > BSpec needs an update based on this ? > It shows > " > HDMI/DVI link rates: 0.2 to 3.0 GHz Non-SSC* > > *2.17 - 2.4 GHz not supported > " Yes, this needs updating. Could you file a change request for it? --Imre > > - Vandana > > + /* CHV DPLL can't generate 216-240 MHz */ > > + if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000) > > return MODE_CLOCK_RANGE; > > > > return MODE_OK; > >
On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > On ma, 2015-07-06 at 14:44 +0300, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Since > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > Author: Vandana Kannan <vandana.kannan@intel.com> > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > drm/i915/bxt: BUNs related to port PLL > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > Adjust the HDMI port clock checks to account for the reduced range > > of invalid frequencies. > > > > Cc: Vandana Kannan <vandana.kannan@intel.com> > > Cc: Imre Deak <imre.deak@intel.com> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Ville wrote a tool for CHV that calculates the valid frequencies based > on the algorithm in the kernel. With the help of that I verified that > this matches the list of target frequencies bxt_find_best_dpll() will > accept, so: Could we have that tool in i-g-t?
On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote: > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > > On ma, 2015-07-06 at 14:44 +0300, ville.syrjala@linux.intel.com wrote: > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > Since > > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > > Author: Vandana Kannan <vandana.kannan@intel.com> > > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > > > drm/i915/bxt: BUNs related to port PLL > > > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > > Adjust the HDMI port clock checks to account for the reduced range > > > of invalid frequencies. > > > > > > Cc: Vandana Kannan <vandana.kannan@intel.com> > > > Cc: Imre Deak <imre.deak@intel.com> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Ville wrote a tool for CHV that calculates the valid frequencies based > > on the algorithm in the kernel. With the help of that I verified that > > this matches the list of target frequencies bxt_find_best_dpll() will > > accept, so: > > Could we have that tool in i-g-t? We could lift all the .find_dpll routines from the kernel into i-g-t. The only real concern is that we'll forget to update the i-g-t copies when changing the kernel. But I guess it would still be easier to just update them slightly when noticing that rather than having to lift them from the kernel all over again.
On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote: > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote: > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > > > On ma, 2015-07-06 at 14:44 +0300, ville.syrjala@linux.intel.com wrote: > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > > Since > > > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > > > Author: Vandana Kannan <vandana.kannan@intel.com> > > > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > > > > > drm/i915/bxt: BUNs related to port PLL > > > > > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > > > Adjust the HDMI port clock checks to account for the reduced range > > > > of invalid frequencies. > > > > > > > > Cc: Vandana Kannan <vandana.kannan@intel.com> > > > > Cc: Imre Deak <imre.deak@intel.com> > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > Ville wrote a tool for CHV that calculates the valid frequencies based > > > on the algorithm in the kernel. With the help of that I verified that > > > this matches the list of target frequencies bxt_find_best_dpll() will > > > accept, so: > > > > Could we have that tool in i-g-t? > > We could lift all the .find_dpll routines from the kernel into i-g-t. > The only real concern is that we'll forget to update the i-g-t copies > when changing the kernel. But I guess it would still be easier to just > update them slightly when noticing that rather than having to lift them > from the kernel all over again. Right, while not ideal, I think having something in i-g-t, even if it diverges slightly (but then we can remind the patch author to update the i-g-t tool during review) is still better than not having that code around at all.
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6726
-------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
ILK 303/303 303/303
SNB +3 309/316 312/316
IVB 343/343 343/343
BYT 285/285 285/285
HSW +13 367/381 380/381
-------------------------------------Detailed-------------------------------------
Platform Test drm-intel-nightly Series Applied
*SNB igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip DMESG_WARN(1) PASS(1)
*SNB igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip DMESG_WARN(1) PASS(1)
*SNB igt@pm_rpm@cursor DMESG_WARN(1) PASS(1)
*SNB igt@pm_rpm@cursor-dpms DMESG_FAIL(1) FAIL(1)
*HSW igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip DMESG_WARN(1) PASS(1)
*HSW igt@pm_lpsp@non-edp DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@debugfs-read DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@gem-idle DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@gem-mmap-gtt DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@gem-pread DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@i2c DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@modeset-non-lpsp DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@modeset-non-lpsp-stress-no-wait DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@pci-d3-state DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@reg-read-ioctl DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@rte DMESG_WARN(1) PASS(1)
*HSW igt@pm_rpm@sysfs-read DMESG_WARN(1) PASS(1)
Note: You need to pay more attention to line start with '*'
On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote: > On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote: > > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote: > > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > > > > On ma, 2015-07-06 at 14:44 +0300, ville.syrjala@linux.intel.com wrote: > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > > > > Since > > > > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > > > > Author: Vandana Kannan <vandana.kannan@intel.com> > > > > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > > > > > > > drm/i915/bxt: BUNs related to port PLL > > > > > > > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > > > > Adjust the HDMI port clock checks to account for the reduced range > > > > > of invalid frequencies. > > > > > > > > > > Cc: Vandana Kannan <vandana.kannan@intel.com> > > > > > Cc: Imre Deak <imre.deak@intel.com> > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > > Ville wrote a tool for CHV that calculates the valid frequencies based > > > > on the algorithm in the kernel. With the help of that I verified that > > > > this matches the list of target frequencies bxt_find_best_dpll() will > > > > accept, so: > > > > > > Could we have that tool in i-g-t? > > > > We could lift all the .find_dpll routines from the kernel into i-g-t. > > The only real concern is that we'll forget to update the i-g-t copies > > when changing the kernel. But I guess it would still be easier to just > > update them slightly when noticing that rather than having to lift them > > from the kernel all over again. > > Right, while not ideal, I think having something in i-g-t, even if it > diverges slightly (but then we can remind the patch author to update the > i-g-t tool during review) is still better than not having that code > around at all. Another way to check this would be to inject EDIDs with hand-rolled timings that increment in small steps. Then we can try modesets on all the unfiltered ones vs. just manually adding it with addmode. If any mode gets filtered inconsistently in the mode list parsing compared to modeset code that would be a bug. Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira for this idea. -Daniel
On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > On ma, 2015-07-06 at 14:44 +0300, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Since > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > Author: Vandana Kannan <vandana.kannan@intel.com> > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > drm/i915/bxt: BUNs related to port PLL > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > Adjust the HDMI port clock checks to account for the reduced range > > of invalid frequencies. > > > > Cc: Vandana Kannan <vandana.kannan@intel.com> > > Cc: Imre Deak <imre.deak@intel.com> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Ville wrote a tool for CHV that calculates the valid frequencies based > on the algorithm in the kernel. With the help of that I verified that > this matches the list of target frequencies bxt_find_best_dpll() will > accept, so: > Reviewed-by: Imre Deak <imre.deak@intel.com> Queued for -next, thanks for the patch. -Daniel
On Mon, 2015-07-13 at 11:05 +0200, Daniel Vetter wrote: > On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote: > > On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote: > > > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote: > > > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > > > > > On ma, 2015-07-06 at 14:44 +0300, ville.syrjala@linux.intel.com wrote: > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > > > > > > Since > > > > > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > > > > > Author: Vandana Kannan <vandana.kannan@intel.com> > > > > > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > > > > > > > > > drm/i915/bxt: BUNs related to port PLL > > > > > > > > > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > > > > > Adjust the HDMI port clock checks to account for the reduced range > > > > > > of invalid frequencies. > > > > > > > > > > > > Cc: Vandana Kannan <vandana.kannan@intel.com> > > > > > > Cc: Imre Deak <imre.deak@intel.com> > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > > > > Ville wrote a tool for CHV that calculates the valid frequencies based > > > > > on the algorithm in the kernel. With the help of that I verified that > > > > > this matches the list of target frequencies bxt_find_best_dpll() will > > > > > accept, so: > > > > > > > > Could we have that tool in i-g-t? > > > > > > We could lift all the .find_dpll routines from the kernel into i-g-t. > > > The only real concern is that we'll forget to update the i-g-t copies > > > when changing the kernel. But I guess it would still be easier to just > > > update them slightly when noticing that rather than having to lift them > > > from the kernel all over again. > > > > Right, while not ideal, I think having something in i-g-t, even if it > > diverges slightly (but then we can remind the patch author to update the > > i-g-t tool during review) is still better than not having that code > > around at all. > > Another way to check this would be to inject EDIDs with hand-rolled > timings that increment in small steps. Then we can try modesets on all the > unfiltered ones vs. just manually adding it with addmode. If any mode gets > filtered inconsistently in the mode list parsing compared to modeset code > that would be a bug. > > Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira > for this idea. > -Daniel if you have dr. HDMI device you can set custom EDID in slots 6 and 7 - works great for this type of exercise with no additional necessary to try out. Jim
On Mon, Jul 13, 2015 at 05:32:14PM +0000, Bish, Jim wrote: > On Mon, 2015-07-13 at 11:05 +0200, Daniel Vetter wrote: > > On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote: > > > On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote: > > > > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote: > > > > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote: > > > > > > On ma, 2015-07-06 at 14:44 +0300, ville.syrjala@linux.intel.com wrote: > > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > > > > > > > > Since > > > > > > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > > > > > > Author: Vandana Kannan <vandana.kannan@intel.com> > > > > > > > Date: Wed Jul 1 17:02:57 2015 +0530 > > > > > > > > > > > > > > drm/i915/bxt: BUNs related to port PLL > > > > > > > > > > > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range. > > > > > > > Adjust the HDMI port clock checks to account for the reduced range > > > > > > > of invalid frequencies. > > > > > > > > > > > > > > Cc: Vandana Kannan <vandana.kannan@intel.com> > > > > > > > Cc: Imre Deak <imre.deak@intel.com> > > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > > > > > > > > > Ville wrote a tool for CHV that calculates the valid frequencies based > > > > > > on the algorithm in the kernel. With the help of that I verified that > > > > > > this matches the list of target frequencies bxt_find_best_dpll() will > > > > > > accept, so: > > > > > > > > > > Could we have that tool in i-g-t? > > > > > > > > We could lift all the .find_dpll routines from the kernel into i-g-t. > > > > The only real concern is that we'll forget to update the i-g-t copies > > > > when changing the kernel. But I guess it would still be easier to just > > > > update them slightly when noticing that rather than having to lift them > > > > from the kernel all over again. > > > > > > Right, while not ideal, I think having something in i-g-t, even if it > > > diverges slightly (but then we can remind the patch author to update the > > > i-g-t tool during review) is still better than not having that code > > > around at all. > > > > Another way to check this would be to inject EDIDs with hand-rolled > > timings that increment in small steps. Then we can try modesets on all the > > unfiltered ones vs. just manually adding it with addmode. If any mode gets > > filtered inconsistently in the mode list parsing compared to modeset code > > that would be a bug. > > > > Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira > > for this idea. > > -Daniel > > if you have dr. HDMI device you can set custom EDID in slots 6 and 7 - > works great for this type of exercise with no additional necessary to > try out. The idea is to be able to run the testsuite with bare-bones machines and no need to send each developer a special piece of hw for each type of output. I know that there are tons of hw solutions for these testing problems, they don't seem to scale well enough. -Daniel
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index c7e912b..70bad5b 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1174,9 +1174,12 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi, if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit)) return MODE_CLOCK_HIGH; - /* CHV/BXT DPLL can't generate 216-240 MHz */ - if ((IS_CHERRYVIEW(dev) || IS_BROXTON(dev)) && - clock > 216000 && clock < 240000) + /* BXT DPLL can't generate 223-240 MHz */ + if (IS_BROXTON(dev) && clock > 223333 && clock < 240000) + return MODE_CLOCK_RANGE; + + /* CHV DPLL can't generate 216-240 MHz */ + if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000) return MODE_CLOCK_RANGE; return MODE_OK;