[Intel-gfx] [PATCH] scripts/kernel-doc: Processing -nofunc for functions only

[Danilo Cesar Lemes de Paula]

Docproc process EXPORT_SYMBOL(f1) macro and uses -nofunc f1 to
avoid duplicated documentation in the next call.
It works for most of the cases, but there are some specific situations
where a struct has the same name of an already-exported function.

Current kernel-doc behavior ignores those structs and do not add them
to the final documentation. This patch fixes it.

This is non-usual and the only case I've found is the drm_modeset_lock
(function and struct) defined in drm_modeset_lock.h and
drm_modeset_lock.c. Considering this, it should only affect the DRM
documentation by including struct drm_modeset_lock to the final Docbook.

Signed-off-by: Danilo Cesar Lemes de Paula 
Cc: Daniel Vetter 
Cc: Jonathan Corbet 
Cc: Andrew Morton 
Cc: Johannes Berg 
Cc: linux-ker...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: intel-gfx 
Cc: dri-devel 
---
 scripts/kernel-doc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 12a106c..047deb7 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1827,7 +1827,7 @@ sub output_declaration {
 my $func = "output_${functype}_$output_mode";
 if (($function_only==0) ||
( $function_only == 1 && defined($function_table{$name})) ||
-   ( $function_only == 2 && !defined($function_table{$name})))
+   ( $function_only == 2 && !($functype eq "function" && 
defined($function_table{$name}
 {
&$func(@_);
$section_counter++;
-- 
2.4.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] scripts/kernel-doc: Improve Markdown results

[Danilo Cesar Lemes de Paula]

On 08/21/2015 04:39 PM, Danilo Cesar Lemes de Paula wrote:
> Using pandoc as the Markdown engine cause some minor side effects as
> pandoc includes  main  tags for almost everything.
> Original Markdown support approach removes those main tags, but it caused
> some inconsistencies when that tag is not the main one, like:
> ..
> ...
> 
> As kernel-doc was already including a  tag, it causes the presence
> of double  tags (), which is not supported by DocBook
> spec.
> 
> Html target gets away with it, so it causes no harm, although other
> targets might not be so lucky (pdf as example).
> 
> We're now delegating the inclusion of the main  tag to pandoc
> only, as it knows when it's necessary or not.
> 
> That behavior causes a corner case, the only situation where we're
> certainly that  is not needed, which is the  content.
> For those cases, we're using a $output_markdown_nopara = 1 control var.
> 
> Signed-off-by: Danilo Cesar Lemes de Paula 
> Cc: Randy Dunlap 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Cc: Jonathan Corbet 
> Cc: Herbert Xu 
> Cc: Stephan Mueller 
> Cc: Michal Marek 
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: intel-gfx 
> Cc: dri-devel 
> Cc: Graham Whaley 
> ---
>  Thanks to Graham Whaley who helped me to debug this.
> 
>  scripts/kernel-doc | 48 ++--
>  1 file changed, 34 insertions(+), 14 deletions(-)
> 
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 3850c1e..12a106c 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -288,6 +288,7 @@ my $use_markdown = 0;
>  my $verbose = 0;
>  my $output_mode = "man";
>  my $output_preformatted = 0;
> +my $output_markdown_nopara = 0;
>  my $no_doc_sections = 0;
>  my @highlights = @highlights_man;
>  my $blankline = $blankline_man;
> @@ -529,8 +530,11 @@ sub markdown_to_docbook {
>   close(CHLD_OUT);
>   close(CHLD_ERR);
>  
> - # pandoc insists in adding Main , we should remove them.
> - $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
> + if ($output_markdown_nopara) {
> + # pandoc insists in adding Main , sometimes we
> + # want to remove them.
> + $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
> + }
>  
>   return $content;
>  }
> @@ -605,7 +609,7 @@ sub output_highlight {
>   $line =~ s/^\s*//;
>   }
>   if ($line eq ""){
> - if (! $output_preformatted) {
> + if (! $output_preformatted && ! $use_markdown) {
>   print $lineprefix, local_unescape($blankline);
>   }
>   } else {
> @@ -1026,7 +1030,7 @@ sub output_section_xml(%) {
>   # programlisting is already included by pandoc
>   print "\n" unless $use_markdown;
>   $output_preformatted = 1;
> - } else {
> + } elsif (! $use_markdown) {
>   print "\n";
>   }
>   output_highlight($args{'sections'}{$section});
> @@ -1034,7 +1038,7 @@ sub output_section_xml(%) {
>   if ($section =~ m/EXAMPLE/i) {
>   print "\n" unless $use_markdown;
>   print "\n";
> - } else {
> + } elsif (! $use_markdown) {
>   print "\n";
>   }
>   print "\n";
> @@ -1066,7 +1070,9 @@ sub output_function_xml(%) {
>  print " " . $args{'function'} . "\n";
>  print " \n";
>  print "  ";
> +$output_markdown_nopara = 1;
>  output_highlight ($args{'purpose'});
> +$output_markdown_nopara = 0;
>  print " \n";
>  print "\n";
>  
> @@ -1104,10 +1110,12 @@ sub output_function_xml(%) {
>   $parameter_name =~ s/\[.*//;
>  
>   print "  \n   
> $parameter\n";
> - print "   \n\n";
> + print "   \n";
> + print "\n" unless $use_markdown;
>   $lineprefix=" ";
>   output_highlight($args{'parameterdescs'}{$parameter_name});
> - print "\n   \n  \n";
> + print "\n" unless $use_markdown;
> + print "   \n  \n";
>   }
>   print " \n";
>  } else {
> @@ -1143,7 +1151,9 @@ sub output_struct_xml(%) {
>  print " " . $args{'type'} . " " . $args{'struct'} . 
> "\n";
>  print " \n";
>  print "  ";
> +$output_markdown_nopara = 1;
>  output_highlight ($args{'purpose'});
> +$output_markdown_nopara = 0;
>  print " \n";
>  print "\n";
>  
> @@ -1196,9 +1206,11 @@ sub output_struct_xml(%) {
>($args{'parameterdescs'}{$parameter_name} ne $undescribed) || next;
>print "";
>print "  $parameter\n";
> -  print "  \n";
> +  print "  \n";
> +  print " \n" unless $use_markdown;
>output_highlight($args{'parameterdescs'}{$parameter_name});
> - 

Re: [Intel-gfx] [PATCH 4/5] Documentation: drm: Convert KMS Properties HTML table to CALS

[Danilo Cesar Lemes de Paula]

On 08/25/2015 01:10 PM, Graham Whaley wrote:
> On Tue, 2015-08-25 at 16:29 +0200, Daniel Vetter wrote:
>> On Tue, Aug 25, 2015 at 10:26:44AM +0100, Graham Whaley wrote:
>>> The KMS Properties table is in HTML format, which is not supported
>>> for building pdfdocs, resulting in the following types of errors:
>>>
>>>  jade:/Documentation/DocBook/drm.xml:34413:15:E: there is no
>>> attribute
>>>  "border"
>>>  jade:/Documentation/DocBook/drm.xml:34413:31:E: there is no
>>> attribute
>>>  "cellpadding"
>>>  jade:/Documentation/DocBook/drm.xml:34413:47:E: there is no
>>> attribute
>>>  "cellspacing"
>>>  jade:/Documentation/DocBook/drm.xml:34414:7:E: document type does
>>> not
>>>  allow element "tbody" here
>>>
>>> Convert the table over to a CALS format table
>>
>> Hm, long-term plan was to move this table into DOC: comments in the
>> source-code using markdown, which we now have (at least in
>> drm-intel-nightly and also planned to be merged into 4.4). Since this
>> is
>> both a lot of churn I'd like to get there in just 1 step ...
>> -Daniel
> First - I've just noted an erroneous debug comment (or two) left in
> this patch as well, so looks like I will have to re-issue the series
> anyway.
> 
> OK. I guess this comes down to a matter of timing...
> From Danilos patch of: f6d6913 (drm/doc: Convert to markdown)
> we can see markdown does not natively support tables, and we'd have to
> make this a fixed width layout like the one in that patch I suspect.
> Danilo - any advice on how you did that other table conversion? I just
> did a pandoc docbook->markdown_github and it looks some way there - but
> of course seems to have not honored the multi-column items, of which
> there are a few. It's probably not too bad to fix up by hand - I'll see
> if I can get that to work...

Hi Graham,

To be honest I didn't have to do any conversion as that table was
already in the header file. I just added 4 spaces so it would be
transformed into fixed width.

However, there's tool you can use to help you: http://pandoc.org/try/
I did a lot of translation there. If your table doesn't have any
spancells, you can put the HTML code there and get the Markdown for free.

Danilo
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check DP link status on long hpd too

[Sivakumar Thulasimani]

On 8/20/2015 10:07 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.

If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meaning the user is
left staring at a blank screen. With the retraining put back that should
be fixed.

Also remove the leftover comment that referred to the old retraining
from .hot_plug().

Fixes a regression introduced in:
commit 0e32b39ceed665bfa4a77a4bc307b6652b991632
Author: Dave Airlie 
Date:   Fri May 2 14:02:48 2014 +1000

 drm/i915: add DP 1.2 MST support (v0.7)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
Cc: Dave Airlie 
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/intel_dp.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d32ce48..b014158 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5024,9 +5024,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
  
  		intel_dp_probe_oui(intel_dp);
  
-		if (!intel_dp_probe_mst(intel_dp))

+   if (!intel_dp_probe_mst(intel_dp)) {
+   drm_modeset_lock(>mode_config.connection_mutex, 
NULL);
+   intel_dp_check_link_status(intel_dp);
+   drm_modeset_unlock(>mode_config.connection_mutex);

couple of queries for my understanding.
> why should we check for link status for long pulse, which is supposed 
to be for plug in or plug out ?
> goto mst_fail will indicate we are falling back to intel_dp_detect, 
isnt this better suited there ?


Also the following bug indicates failure in mst panel, but the changes 
here are in non-mst path
 https://bugs.freedesktop.org/show_bug.cgi?id=89453, how is this 
patch helping this bug ?

goto mst_fail;
-
+   }
} else {
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
@@ -5034,10 +5037,6 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp->is_mst) {

-   /*
-* we'll check the link status via the normal hot plug 
path later -
-* but for short hpds we should check it now
-*/
drm_modeset_lock(>mode_config.connection_mutex, 
NULL);
intel_dp_check_link_status(intel_dp);
drm_modeset_unlock(>mode_config.connection_mutex);


--
regards,
Sivakumar

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Check DP link status on long hpd too

[Ville Syrjälä]

On Tue, Sep 01, 2015 at 11:36:25PM +0530, Sivakumar Thulasimani wrote:
> 
> 
> On 8/20/2015 10:07 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > We are no longer checkling the DP link status on long hpd. We used to do
> > that from the .hot_plug() handler, but it was removed when MST got
> > introduced.
> >
> > If there's no userspace we now fail to retrain the link if the sink
> > power is toggled (or cable yanked and replugged), meaning the user is
> > left staring at a blank screen. With the retraining put back that should
> > be fixed.
> >
> > Also remove the leftover comment that referred to the old retraining
> > from .hot_plug().
> >
> > Fixes a regression introduced in:
> > commit 0e32b39ceed665bfa4a77a4bc307b6652b991632
> > Author: Dave Airlie 
> > Date:   Fri May 2 14:02:48 2014 +1000
> >
> >  drm/i915: add DP 1.2 MST support (v0.7)
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
> > Cc: Dave Airlie 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/intel_dp.c | 11 +--
> >   1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index d32ce48..b014158 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -5024,9 +5024,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> > *intel_dig_port, bool long_hpd)
> >   
> > intel_dp_probe_oui(intel_dp);
> >   
> > -   if (!intel_dp_probe_mst(intel_dp))
> > +   if (!intel_dp_probe_mst(intel_dp)) {
> > +   drm_modeset_lock(>mode_config.connection_mutex, 
> > NULL);
> > +   intel_dp_check_link_status(intel_dp);
> > +   drm_modeset_unlock(>mode_config.connection_mutex);
> couple of queries for my understanding.
>  > why should we check for link status for long pulse, which is supposed 
> to be for plug in or plug out ?
>  > goto mst_fail will indicate we are falling back to intel_dp_detect, 
> isnt this better suited there ?

->detect() should do what it says and no more.

In any case I think it's better to have the code to maintain the current
link in one place. That should also make the locking rules easier to
understand since we hpd_pulse and detect are executed from different
works.

> 
> Also the following bug indicates failure in mst panel, but the changes 
> here are in non-mst path
>   https://bugs.freedesktop.org/show_bug.cgi?id=89453, how is this 
> patch helping this bug ?

Presumably the monitor is being used in non-MST mode.

> > goto mst_fail;
> > -
> > +   }
> > } else {
> > if (intel_dp->is_mst) {
> > if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
> > @@ -5034,10 +5037,6 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> > *intel_dig_port, bool long_hpd)
> > }
> >   
> > if (!intel_dp->is_mst) {
> > -   /*
> > -* we'll check the link status via the normal hot plug 
> > path later -
> > -* but for short hpds we should check it now
> > -*/
> > drm_modeset_lock(>mode_config.connection_mutex, 
> > NULL);
> > intel_dp_check_link_status(intel_dp);
> > drm_modeset_unlock(>mode_config.connection_mutex);
> 
> -- 
> regards,
> Sivakumar

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Request Linux Graphic Driver for Intel GMA 3150

[Jani Nikula]

On Sat, 22 Aug 2015, David Ho  wrote:
> REQUEST
>
> May I please request support for driver of Intel GMA 3150 for Ubuntu 14.04.3
> 32 bit (Trusty Tahr)?
>
> I installed "Intel Graphic Installer for Linux" from 01.org, but it stops at
> the very first step saying "Distribution not supported".

Rodrigo (Cc'd) knows this stuff better, but I don't think it's likely
old (from upstream POV) distros will be supported. In that regard,
you're probably better off asking help from your distro vendor.

> BACKGROUND
>
> After fresh install of 14.04, the mouse pointer is not showing up and the
> display change (when scrolling, moving between windows, etc) is very slow
> (even only for regular application, never tried to watch video yet). I
> concluded that this is the driver issue.

Does it work on a newer Ubuntu install? Or can you try a new kernel? If
you can reproduce this on a new kernel, please file a bug at [1].

BR,
Jani.



[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


>
> I must install it for around 20 PCs.
>
> Please help me to get the correct driver.
>
>  
>
> Thank you.
>
>  
>
> Regards,
>
> David Ho
>
>  
>
>  
>
> -Original Message-
> From: Chacn Limn, DanielX [mailto:danielx.chacn.l...@intel.com] 
> Sent: 21 Agustus 2015 22:05
> To: hupernikao...@gmail.com
> Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Diaz, Victor H
> Subject: RE: [Contact] Intel GMA 3150 for Ubuntu 14.04.3Trusty Tahr 32bit
>
>  
>
> Hi David,
>
> Thank you for contacting us.
>
>  
>
> For help or more information about Linux Graphics drivers please contact the
> Team in charge through their mailing list:
>
>   intel-gfx@lists.freedesktop.org
>
>  
>
> Regards,
>
> Daniel.
>
>  
>
> [.MESSAGES TRUNCATED]
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 12/22] drm/i915: Preserve SSC earlier

[Jani Nikula]

On Mon, 31 Aug 2015, Jesse Barnes  wrote:
> On 07/15/2015 04:57 AM, Lukas Wunner wrote:
>> Commit 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
>> added code to intel_modeset_gem_init to override the SSC status read
>> from VBT with the SSC status set by BIOS.
>> 
>> However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
>> which calls intel_setup_outputs, which *modifies* SSC status by way of
>> intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
>> doesn't preserve the SSC status set by BIOS but whatever
>> intel_init_pch_refclk decided on.
>> 
>> This is a problem on dual gpu laptops such as the MacBook Pro which
>> require either a handler to switch DDC lines, or the discrete gpu
>> to proxy DDC/AUX communication: Both the handler and the discrete
>> gpu may initialize after the i915 driver, and consequently, an LVDS
>> connector may initially seem disconnected and the SSC therefore
>> is disabled by intel_init_pch_refclk, but on reprobe the connector
>> may turn out to be connected and the SSC must then be enabled.
>> 
>> Due to 92122789b2d6 however, the SSC is not enabled on reprobe since
>> it is assumed BIOS disabled it while in fact it was disabled by
>> intel_init_pch_refclk.
>> 
>> Also, because the SSC status is preserved so late, the preserved value
>> only ever gets used on resume but not on panel initialization:
>> intel_modeset_init calls intel_init_display which indirectly calls
>> intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
>> overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
>> is the sole user of dev_priv->vbt.lvds_use_ssc).
>> 
>> Fix this by moving the code introduced by 92122789b2d6 from
>> intel_modeset_gem_init to intel_modeset_init before the invocation
>> of intel_setup_outputs and intel_init_display.
>> 
>> Add a DRM_DEBUG_KMS as suggested way back by Jani:
>> http://lists.freedesktop.org/archives/intel-gfx/2014-June/04.html
>> 
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
>> Tested-by: Paul Hordiienko 
>> [MBP  6,2 2010  intel ILK + nvidia GT216  pre-retina]
>> Tested-by: William Brown 
>> [MBP  8,2 2011  intel SNB + amd turks pre-retina]
>> Tested-by: Lukas Wunner 
>> [MBP  9,1 2012  intel IVB + nvidia GK107  pre-retina]
>> Tested-by: Bruno Bierbaumer 
>> [MBP 11,3 2013  intel HSW + nvidia GK107  retina -- work in progress]
>> 
>> Fixes: 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
>> Signed-off-by: Lukas Wunner 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 29 ++---
>>  1 file changed, 18 insertions(+), 11 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index af0bcfe..6335883 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14893,6 +14893,24 @@ void intel_modeset_init(struct drm_device *dev)
>>  if (INTEL_INFO(dev)->num_pipes == 0)
>>  return;
>>  
>> +/*
>> + * There may be no VBT; and if the BIOS enabled SSC we can
>> + * just keep using it to avoid unnecessary flicker.  Whereas if the
>> + * BIOS isn't using it, don't assume it will work even if the VBT
>> + * indicates as much.
>> + */
>> +if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
>> +bool bios_lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
>> +DREF_SSC1_ENABLE);
>> +
>> +if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
>> +DRM_DEBUG_KMS("SSC %sabled by BIOS, overriding VBT 
>> which says %sabled\n",
>> + bios_lvds_use_ssc ? "en" : "dis",
>> + dev_priv->vbt.lvds_use_ssc ? "en" : "dis");
>> +dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
>> +}
>> +}
>> +
>>  intel_init_display(dev);
>>  intel_init_audio(dev);
>>  
>> @@ -15446,7 +15464,6 @@ err:
>>  
>>  void intel_modeset_gem_init(struct drm_device *dev)
>>  {
>> -struct drm_i915_private *dev_priv = dev->dev_private;
>>  struct drm_crtc *c;
>>  struct drm_i915_gem_object *obj;
>>  int ret;
>> @@ -15455,16 +15472,6 @@ void intel_modeset_gem_init(struct drm_device *dev)
>>  intel_init_gt_powersave(dev);
>>  mutex_unlock(>struct_mutex);
>>  
>> -/*
>> - * There may be no VBT; and if the BIOS enabled SSC we can
>> - * just keep using it to avoid unnecessary flicker.  Whereas if the
>> - * BIOS isn't using it, don't assume it will work even if the VBT
>> - * indicates as much.
>> - */
>> -if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
>> -dev_priv->vbt.lvds_use_ssc = 

Re: [Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro

[Jani Nikula]

On Mon, 31 Aug 2015, Jani Nikula  wrote:
> On Sat, 29 Aug 2015, Lukas Wunner  wrote:
>> Hi Daniel, Hi Jani,
>>
>> the patch set I've posted August 12 included 3 commits which fix bugs
>> in i915. These bugs should be fixed independently of MacBook Pro GPU
>> switching, please consider merging them:
>>
>> drm/i915: Preserve SSC earlier
>> http://patchwork.freedesktop.org/patch/56921/

Pushed this one.

Jani.

>>
>> drm/i915: Fix failure paths around initial fbdev allocation
>> http://patchwork.freedesktop.org/patch/53673/
>> drm/i915: On fb alloc failure, unref gem object where it gets refed
>> http://patchwork.freedesktop.org/patch/53674/
>>
>> The latter two commits relate to a bug Jani was tracking before his
>> holidays which has unfortunately fallen by the wayside.
>
> Sorry about that. Unfortunately the target is moving fast, and they no
> longer apply. Please resend on top of current nightly.
>
> BR,
> Jani.
>
>
>>
>> Thanks,
>>
>> Lukas
>
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Fix bookkeeping with TEST_ONLY, v3.

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 7289
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
ILK -2  255/255  253/255
SNB  248/248  248/248
IVB  281/281  281/281
BYT  234/234  234/234
HSW  317/317  317/317
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt@gem_fence_thrash@bo-write-verify-threaded-none  PASS(1)  
NO_RESULT(1)
*ILK  igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing   
   PASS(1)  DMESG_WARN(1)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

[Egbert Eich]

drm_kms_helper_poll_enable() was converted to lock the mode_config
mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").

This disregarded the cases where this function is called from a context
where this mutex is already locked.

Add a non-locking version as well.

Signed-off-by: Egbert Eich 
---
 drivers/gpu/drm/drm_probe_helper.c | 19 ---
 include/drm/drm_crtc_helper.h  |  1 +
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index d734780..a93ad1b 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -93,8 +93,19 @@ static int drm_helper_probe_add_cmdline_mode(struct 
drm_connector *connector)
return 1;
 }
 
+/**
+ * drm_kms_helper_poll_enable_no_lock - re-enable output polling.
+ * @dev: drm_device
+ *
+ * This function re-enables the output polling work without
+ * locking the mode_config mutex.
+ *
+ * This is like drm_kms_helper_poll_enable() however it is to be
+ * called from a context where the mode_config mutex is locked
+ * already.
+ */
 #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
-static void __drm_kms_helper_poll_enable(struct drm_device *dev)
+void drm_kms_helper_poll_enable_no_lock(struct drm_device *dev)
 {
bool poll = false;
struct drm_connector *connector;
@@ -113,6 +124,8 @@ static void __drm_kms_helper_poll_enable(struct drm_device 
*dev)
if (poll)
schedule_delayed_work(>mode_config.output_poll_work, 
DRM_OUTPUT_POLL_PERIOD);
 }
+EXPORT_SYMBOL(drm_kms_helper_poll_enable_no_lock);
+
 
 static int drm_helper_probe_single_connector_modes_merge_bits(struct 
drm_connector *connector,
  uint32_t maxX, 
uint32_t maxY, bool merge_type_bits)
@@ -174,7 +187,7 @@ static int 
drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
 
/* Re-enable polling in case the global poll config changed. */
if (drm_kms_helper_poll != dev->mode_config.poll_running)
-   __drm_kms_helper_poll_enable(dev);
+   drm_kms_helper_poll_enable_no_lock(dev);
 
dev->mode_config.poll_running = drm_kms_helper_poll;
 
@@ -428,7 +441,7 @@ EXPORT_SYMBOL(drm_kms_helper_poll_disable);
 void drm_kms_helper_poll_enable(struct drm_device *dev)
 {
mutex_lock(>mode_config.mutex);
-   __drm_kms_helper_poll_enable(dev);
+   drm_kms_helper_poll_enable_no_lock(dev);
mutex_unlock(>mode_config.mutex);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 2a747a9..f96703d 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -240,5 +240,6 @@ extern void drm_kms_helper_hotplug_event(struct drm_device 
*dev);
 
 extern void drm_kms_helper_poll_disable(struct drm_device *dev);
 extern void drm_kms_helper_poll_enable(struct drm_device *dev);
+extern void drm_kms_helper_poll_enable_no_lock(struct drm_device *dev);
 
 #endif
-- 
1.8.4.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/4] Fix numerous issues with HPDstorm handling

[Egbert Eich]

The following 4 patches fix issues with the HPD storm detection.
Two of them have been introduced quite recently, one has been
around since this code was implemented.
Work arounds like:
commit 3ff04a160a891e56cdcee5c198d4c764d1c8c78b
("drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms")
and
commit 3432087ef846d760427eceff0ff4e7d0a2565b8a
("drm/i915: Only WARN about a stuck hotplug irq ONCE")
may actually become obsolete now.

Egbert Eich (4):
  drm: Add a non-locking version of drm_kms_helper_poll_enable().
  drm/i915: Call non-locking version of drm_kms_helper_poll_enable()
  drm/i915: Use the correct hpd_status list for non-G4xx/VLV
  drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt

 drivers/gpu/drm/drm_probe_helper.c   | 19 ---
 drivers/gpu/drm/i915/i915_irq.c  |  2 +-
 drivers/gpu/drm/i915/intel_crt.c | 17 -
 drivers/gpu/drm/i915/intel_hotplug.c |  2 +-
 include/drm/drm_crtc_helper.h|  1 +
 5 files changed, 31 insertions(+), 10 deletions(-)

-- 
1.8.4.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915: Use the correct hpd_status list for non-G4xx/VLV

[Egbert Eich]

This copy-and-past error was introduced in:

commit fd63e2a972c670887e5e8a08440111d3812c0996
Author: Imre Deak 
Date:   Tue Jul 21 15:32:44 2015 -0700

drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins

Signed-off-by: Egbert Eich 
---
 drivers/gpu/drm/i915/i915_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8485bea..ad99dae 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1559,7 +1559,7 @@ static void i9xx_hpd_irq_handler(struct drm_device *dev)
u32 hotplug_trigger = hotplug_status & HOTPLUG_INT_STATUS_I915;
 
intel_get_hpd_pins(_mask, _mask, hotplug_trigger,
-  hotplug_trigger, hpd_status_g4x,
+  hotplug_trigger, hpd_status_i915,
   i9xx_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
-- 
1.8.4.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/4] drm/i915: Call non-locking version of drm_kms_helper_poll_enable()

[Egbert Eich]

drm_kms_helper_poll_enable() is called from a context in
intel_hpd_irq_storm_disable() where the the mode_config mutex is
already locked.
When this function was converted to lock this mutex in:

commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
Author: Daniel Vetter 
Date:   Thu Jul 9 23:44:26 2015 +0200

drm/probe-helper: Grab mode_config.mutex in poll_init/enable

a deadlock occurred.
Call the newly implemented non-locking version of this function.

Signed-off-by: Egbert Eich 
---
 drivers/gpu/drm/i915/intel_hotplug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 53c0173..77dd5b6 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -180,7 +180,7 @@ static void intel_hpd_irq_storm_disable(struct 
drm_i915_private *dev_priv)
 
/* Enable polling and queue hotplug re-enabling. */
if (hpd_disabled) {
-   drm_kms_helper_poll_enable(dev);
+   drm_kms_helper_poll_enable_no_lock(dev);
mod_delayed_work(system_wq, _priv->hotplug.reenable_work,
 msecs_to_jiffies(HPD_STORM_REENABLE_DELAY));
}
-- 
1.8.4.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/4] drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt

[Egbert Eich]

A HPD interrupt may fire during intel_crt_detect_hotplug() - especially
when HPD interrupt storms occur.
Since the interrupt handler changes the enabled interrupt lines when it
detects a storm this races with intel_crt_detect_hotplug().
To avoid this, shiled the rmw cycles with IRQ save spinlocks.

Signed-off-by: Egbert Eich 
---
 drivers/gpu/drm/i915/intel_crt.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index af5e43b..685f3de 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -376,9 +376,10 @@ static bool intel_crt_detect_hotplug(struct drm_connector 
*connector)
 {
struct drm_device *dev = connector->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 hotplug_en, orig, stat;
+   u32 hotplug_en, stat;
bool ret = false;
int i, tries = 0;
+   unsigned long irqflags;
 
if (HAS_PCH_SPLIT(dev))
return intel_ironlake_crt_detect_hotplug(connector);
@@ -395,12 +396,14 @@ static bool intel_crt_detect_hotplug(struct drm_connector 
*connector)
tries = 2;
else
tries = 1;
-   hotplug_en = orig = I915_READ(PORT_HOTPLUG_EN);
-   hotplug_en |= CRT_HOTPLUG_FORCE_DETECT;
 
for (i = 0; i < tries ; i++) {
/* turn on the FORCE_DETECT */
-   I915_WRITE(PORT_HOTPLUG_EN, hotplug_en);
+   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   hotplug_en = I915_READ(PORT_HOTPLUG_EN);
+   I915_WRITE(PORT_HOTPLUG_EN, hotplug_en |
+  CRT_HOTPLUG_FORCE_DETECT);
+   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
/* wait for FORCE_DETECT to go off */
if (wait_for((I915_READ(PORT_HOTPLUG_EN) &
  CRT_HOTPLUG_FORCE_DETECT) == 0,
@@ -416,7 +419,11 @@ static bool intel_crt_detect_hotplug(struct drm_connector 
*connector)
I915_WRITE(PORT_HOTPLUG_STAT, CRT_HOTPLUG_INT_STATUS);
 
/* and put the bits back */
-   I915_WRITE(PORT_HOTPLUG_EN, orig);
+   spin_lock_irqsave(_priv->irq_lock, irqflags);
+   hotplug_en = I915_READ(PORT_HOTPLUG_EN);
+   hotplug_en &= ~CRT_HOTPLUG_FORCE_DETECT;
+   I915_WRITE(PORT_HOTPLUG_EN, hotplug_en);
+   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
 
return ret;
 }
-- 
1.8.4.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

[Lukas Wunner]

Hi Egbert,

On Tue, Sep 01, 2015 at 10:21:32PM +0200, Egbert Eich wrote:
> drm_kms_helper_poll_enable() was converted to lock the mode_config
> mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
> ("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").
> 
> This disregarded the cases where this function is called from a context
> where this mutex is already locked.

Which ones would that be?


> + * drm_kms_helper_poll_enable_no_lock - re-enable output polling.

It seems DRM convention is to append _locked or _unlocked, e.g.:
drm_fb_helper_restore_fbdev_mode_unlocked
drm_gem_object_unreference_unlocked


Best regards,

Lukas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

[Egbert Eich]

Lukas Wunner writes:
 > 
 > It seems DRM convention is to append _locked or _unlocked, e.g.:
 > drm_fb_helper_restore_fbdev_mode_unlocked
 > drm_gem_object_unreference_unlocked
 > 

Oh, I missed that. 
Did you check what these functions actually do - and compare it to
what I try to achieve?

Egbert.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

[Egbert Eich]

Lukas Wunner writes:
 > Hi Egbert,
 > 
 > On Tue, Sep 01, 2015 at 10:21:32PM +0200, Egbert Eich wrote:
 > > drm_kms_helper_poll_enable() was converted to lock the mode_config
 > > mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
 > > ("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").
 > > 
 > > This disregarded the cases where this function is called from a context
 > > where this mutex is already locked.
 > 
 > Which ones would that be?

Have you missed the next patch in the series?

Egbert.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

[Lukas Wunner]

Hi Egbert,

On Wed, Sep 02, 2015 at 12:10:19AM +0200, Egbert Eich wrote:
> Lukas Wunner writes:
>  > On Tue, Sep 01, 2015 at 10:21:32PM +0200, Egbert Eich wrote:
>  > > drm_kms_helper_poll_enable() was converted to lock the mode_config
>  > > mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
>  > > ("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").
>  > > 
>  > > This disregarded the cases where this function is called from a context
>  > > where this mutex is already locked.
>  > 
>  > Which ones would that be?
> 
> Have you missed the next patch in the series?

Sorry, I should have asked more precisely: Is this the only one?
If so it may make sense to modify i915_hotplug_work_func or
intel_hpd_irq_storm_disable instead.

Best regards,

Lukas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/dp: use the drm dp helper for determining sink tps3 support

[Daniel Vetter]

On Thu, Aug 27, 2015 at 01:25:37PM +0300, Jani Nikula wrote:
> No functional changes.
> 
> Signed-off-by: Jani Nikula 

Merged the first 2 patches to dinq (rebased on top of the drm dp helper as
the series originally did). But can't merge more since this depends upon
the tp3 reverts in dinf, so need a suitable backmerge first.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] drm/i915: Postpone plane readout until after encoder readout, v2.

[Daniel Vetter]

On Thu, Aug 27, 2015 at 01:05:12PM +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 26-08-15 om 16:43 schreef Daniel Vetter:
> > On Wed, Aug 05, 2015 at 12:45:48PM +0200, Maarten Lankhorst wrote:
> >> From: Patrik Jakobsson 
> >>
> >> When reading out hw state for planes we disable inactive planes which in
> >> turn triggers an update of the watermarks. The update depends on the
> >> crtc_clock being set which is done when reading out encoders. Thus
> >> postpone the plane readout until after encoder readout.
> >>
> >> This prevents a warning in skl_compute_linetime_wm() where pixel_rate
> >> becomes 0 when crtc_clock is 0.
> >>
> >> Changes since v1:
> >> - Set all modes after all state is read out. (Maarten)
> >>
> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=91428
> >> Signed-off-by: Patrik Jakobsson 
> >> Signed-off-by: Maarten Lankhorst 
> > Hm I still think we have a bit a mess here - the plane readout code is
> > still spread out between modeset_readout_hw_state and the per-plane loop
> > in intel_modeset_init after setup_hw_state.
> >
> > I thought that we only ever need to do the plane state readout on initial
> > load (they're all off on resume anyway and we force a full modeset to make
> > sure plane state is correct again). Can't we just have a setup_plane_state
> > which has that loop from the end of modeset_init with all the other plane
> > state unified there?
> >
> Perhaps, but intel_crtc_disable_noatomic cares about visibility state.

I don't see a need for that any more at all, since disable_noatomic is
only used in sanitize_crtc. And that's only called when the bios fucks
something up and i915.ko needs to patch it up. No way a pageflip or
anything else is pending there. Also we don't seem to set up plane_mask
early enough for that function to correctly kill the primary plane.

That might explain some of the display faults Chris is seeing ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps

[Michał Winiarski]

On each call to gen8_alloc_va_range_3lvl we're allocating temporary
bitmaps needed for error handling. Unfortunately, when we increase
address space size (48b ppgtt) we do additional (512 - 4) calls to
kcalloc, increasing latency between exec and actual start of execution
on the GPU. Let's just do a single kcalloc, we can also drop the size
from free_gen8_temp_bitmaps since it's no longer used.

v2: Use GFP_TEMPORARY to make the allocations reclaimable.
v3: Drop the 2D array, just allocate a single block.

Cc: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Michel Thierry 
Signed-off-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 45 +
 1 file changed, 16 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4a76807..f810762 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1126,13 +1126,8 @@ unwind_out:
 }
 
 static void
-free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned long **new_pts,
-  uint32_t pdpes)
+free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned long *new_pts)
 {
-   int i;
-
-   for (i = 0; i < pdpes; i++)
-   kfree(new_pts[i]);
kfree(new_pts);
kfree(new_pds);
 }
@@ -1142,29 +1137,20 @@ free_gen8_temp_bitmaps(unsigned long *new_pds, unsigned 
long **new_pts,
  */
 static
 int __must_check alloc_gen8_temp_bitmaps(unsigned long **new_pds,
-unsigned long ***new_pts,
+unsigned long **new_pts,
 uint32_t pdpes)
 {
-   int i;
unsigned long *pds;
-   unsigned long **pts;
+   unsigned long *pts;
 
-   pds = kcalloc(BITS_TO_LONGS(pdpes), sizeof(unsigned long), GFP_KERNEL);
+   pds = kcalloc(BITS_TO_LONGS(pdpes), sizeof(unsigned long), 
GFP_TEMPORARY);
if (!pds)
return -ENOMEM;
 
-   pts = kcalloc(pdpes, sizeof(unsigned long *), GFP_KERNEL);
-   if (!pts) {
-   kfree(pds);
-   return -ENOMEM;
-   }
-
-   for (i = 0; i < pdpes; i++) {
-   pts[i] = kcalloc(BITS_TO_LONGS(I915_PDES),
-sizeof(unsigned long), GFP_KERNEL);
-   if (!pts[i])
-   goto err_out;
-   }
+   pts = kcalloc(pdpes * BITS_TO_LONGS(I915_PDES),
+   sizeof(unsigned long), GFP_TEMPORARY);
+   if (!pts)
+   goto err_out;
 
*new_pds = pds;
*new_pts = pts;
@@ -1172,7 +1158,7 @@ int __must_check alloc_gen8_temp_bitmaps(unsigned long 
**new_pds,
return 0;
 
 err_out:
-   free_gen8_temp_bitmaps(pds, pts, pdpes);
+   free_gen8_temp_bitmaps(pds, pts);
return -ENOMEM;
 }
 
@@ -1193,7 +1179,7 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
 {
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
-   unsigned long *new_page_dirs, **new_page_tables;
+   unsigned long *new_page_dirs, *new_page_tables;
struct drm_device *dev = vm->dev;
struct i915_page_directory *pd;
const uint64_t orig_start = start;
@@ -1220,14 +1206,14 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
ret = gen8_ppgtt_alloc_page_directories(vm, pdp, start, length,
new_page_dirs);
if (ret) {
-   free_gen8_temp_bitmaps(new_page_dirs, new_page_tables, pdpes);
+   free_gen8_temp_bitmaps(new_page_dirs, new_page_tables);
return ret;
}
 
/* For every page directory referenced, allocate page tables */
gen8_for_each_pdpe(pd, pdp, start, length, temp, pdpe) {
ret = gen8_ppgtt_alloc_pagetabs(vm, pd, start, length,
-   new_page_tables[pdpe]);
+   new_page_tables + pdpe * 
BITS_TO_LONGS(I915_PDES));
if (ret)
goto err_out;
}
@@ -1278,20 +1264,21 @@ static int gen8_alloc_va_range_3lvl(struct 
i915_address_space *vm,
gen8_setup_page_directory(ppgtt, pdp, pd, pdpe);
}
 
-   free_gen8_temp_bitmaps(new_page_dirs, new_page_tables, pdpes);
+   free_gen8_temp_bitmaps(new_page_dirs, new_page_tables);
mark_tlbs_dirty(ppgtt);
return 0;
 
 err_out:
while (pdpe--) {
-   for_each_set_bit(temp, new_page_tables[pdpe], I915_PDES)
+   for_each_set_bit(temp, new_page_tables + pdpe *
+   BITS_TO_LONGS(I915_PDES), I915_PDES)
free_pt(dev, 
pdp->page_directory[pdpe]->page_table[temp]);
}
 
   

Re: [Intel-gfx] [PATCH 02/16] drm/i915: fix the FBC work allocation failure path

[Daniel Vetter]

On Fri, Aug 28, 2015 at 11:50:08AM -0300, Paulo Zanoni wrote:
> 2015-08-28 11:20 GMT-03:00 Ville Syrjälä :
> > On Fri, Aug 14, 2015 at 06:34:07PM -0300, Paulo Zanoni wrote:
> >> Always update the currrent crtc, fb and vertical offset after calling
> >> enable_fbc. We were forgetting to do so along the failure paths when
> >> enabling fbc synchronously. Fix this with a new helper to enable_fbc()
> >> and update the state simultaneously.
> >>
> >> v2: Improve commit message (Chris).
> >>
> >> Signed-off-by: Paulo Zanoni 
> >> ---
> >>  drivers/gpu/drm/i915/intel_fbc.c | 27 +--
> >>  1 file changed, 17 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> >> b/drivers/gpu/drm/i915/intel_fbc.c
> >> index c97aba2..fa9b004 100644
> >> --- a/drivers/gpu/drm/i915/intel_fbc.c
> >> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> >> @@ -308,6 +308,18 @@ bool intel_fbc_enabled(struct drm_i915_private 
> >> *dev_priv)
> >>   return dev_priv->fbc.enabled;
> >>  }
> >>
> >> +static void intel_fbc_enable(struct intel_crtc *crtc,
> >> +  struct drm_framebuffer *fb)
> >
> > fb could be const
> 
> I guess a lot of things could be constified, if we decide to do this.

Personally I like const on .data (especially vfunc tables since those are
nice to create exploits if they're writable and you can get at them). And
for core functions/vfuncs where the const has a semantic meaning.
Otherwise I personally don't see to much value in sprinkling const all
over.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Move intel_crtc_disable_noatomic to intel_sanitize_crtc.

[Maarten Lankhorst]

To make it clear it is only called from that function.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 54 ++--
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 904e900c0d83..eacb911b2636 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6142,33 +6142,6 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
intel_update_watermarks(crtc);
 }
 
-static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
-{
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
-   enum intel_display_power_domain domain;
-   unsigned long domains;
-
-   if (!intel_crtc->active)
-   return;
-
-   if (to_intel_plane_state(crtc->primary->state)->visible) {
-   unsigned plane_mask = 1 << drm_plane_index(crtc->primary);
-
-   intel_pre_disable_primary(crtc);
-
-   intel_crtc_disable_planes(crtc, plane_mask);
-   }
-
-   dev_priv->display.crtc_disable(crtc);
-   intel_disable_shared_dpll(intel_crtc);
-
-   domains = intel_crtc->enabled_power_domains;
-   for_each_power_domain(domain, domains)
-   intel_display_power_put(dev_priv, domain);
-   intel_crtc->enabled_power_domains = 0;
-}
-
 /*
  * turn all crtc's off, but do not adjust state
  * This has to be paired with a call to intel_modeset_setup_hw_state.
@@ -14826,6 +14799,33 @@ intel_check_plane_mapping(struct intel_crtc *crtc)
return true;
 }
 
+static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
+{
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+   enum intel_display_power_domain domain;
+   unsigned long domains;
+
+   if (!intel_crtc->active)
+   return;
+
+   if (to_intel_plane_state(crtc->primary->state)->visible) {
+   unsigned plane_mask = 1 << drm_plane_index(crtc->primary);
+
+   intel_pre_disable_primary(crtc);
+
+   intel_crtc_disable_planes(crtc, plane_mask);
+   }
+
+   dev_priv->display.crtc_disable(crtc);
+   intel_disable_shared_dpll(intel_crtc);
+
+   domains = intel_crtc->enabled_power_domains;
+   for_each_power_domain(domain, domains)
+   intel_display_power_put(dev_priv, domain);
+   intel_crtc->enabled_power_domains = 0;
+}
+
 static void intel_sanitize_crtc(struct intel_crtc *crtc)
 {
struct drm_device *dev = crtc->base.dev;
-- 
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Fix intel_crtc_disable_noatomic disabling.

[Maarten Lankhorst]

plane_mask is not accurate during hw readout,
use 1 << drm_plane_index(primary) instead.

wait_for_pending_flips should be a noop now. This function is now
only called during init or resume sanitization. In both cases
there are no pending flips from the driver.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 69c95213c27b..904e900c0d83 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6153,11 +6153,13 @@ static void intel_crtc_disable_noatomic(struct drm_crtc 
*crtc)
return;
 
if (to_intel_plane_state(crtc->primary->state)->visible) {
-   intel_crtc_wait_for_pending_flips(crtc);
+   unsigned plane_mask = 1 << drm_plane_index(crtc->primary);
+
intel_pre_disable_primary(crtc);
+
+   intel_crtc_disable_planes(crtc, plane_mask);
}
 
-   intel_crtc_disable_planes(crtc, crtc->state->plane_mask);
dev_priv->display.crtc_disable(crtc);
intel_disable_shared_dpll(intel_crtc);
 
-- 
2.1.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: read sink_count dpcd always

[Jani Nikula]

On Thu, 27 Aug 2015, Sivakumar Thulasimani  
wrote:
> From: "Thulasimani,Sivakumar" 
>
> This patch reads sink_count dpcd always and removes its
> read operation based on values in downstream port dpcd.
>
> SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
> SINK_COUNT denotes if a display is attached, while
> DOWNSTREAM_PORT_PRESET indicates how many ports are available
> in the dongle where display can be attached. so it is possible
> for sink count to change irrespective of value in downstream
> port dpcd.

This makes sense.

I'm scared this may break something, if there are displays/adapters out
there that don't set sink count properly. I guess only one way to find
out... And this might actually fix something else.

> Here is a table of possible values and scenarios
>
> sink_count  downstream_port
> present
> 0   0   no display is attached
> 0   1   dongle is connected without display
> 1   0   display connected directly
> 1   1   display connected through dongle

Do you think you handle this last case properly now? Previously we'd
return with "connected" at the sink count check, but now we'll go for
the "pke ddc gently" phase.

See below.

>
> v2: moved out crtc enabled checks to prior patch(Jani)
>
> Signed-off-by: Sivakumar Thulasimani 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 76561e0..9e4e27d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   uint8_t rev;
> + uint8_t reg;
>  
>   if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
>   sizeof(intel_dp->dpcd)) < 0)
> @@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   if (intel_dp->dpcd[DP_DPCD_REV] == 0)
>   return false; /* DPCD not present */
>  
> + if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
> + , 1) < 0)
> + return false;
> +
> + if (!DP_GET_SINK_COUNT(reg))
> + return false;
> +
>   /* Check if the panel supports PSR */
>   memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
>   if (is_edp(intel_dp)) {
> @@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
>   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
>   return connector_status_connected;
>  
> - /* If we're HPD-aware, SINK_COUNT changes dynamically */
> - if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
> - intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
> - uint8_t reg;
> -
> - if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
> - , 1) < 0)
> - return connector_status_unknown;
> -
> - return DP_GET_SINK_COUNT(reg) ? connector_status_connected
> -   : connector_status_disconnected;
> - }
> -

Why do we proceed here if we know that we have sink count > 0 and we
have a downstream port present? Admittedly I'm not sure I understand (or
remember) why we had this logic in the first place...

BR,
Jani.

>   /* If no HPD, poke DDC gently */
>   if (drm_probe_ddc(_dp->aux.ddc))
>   return connector_status_connected;
> -- 
> 1.7.9.5
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Tomi Valkeinen]

On 25/08/15 22:24, Rob Clark wrote:
> On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  wrote:
>> When the usual fbcon legacy options are enabled we have
>> ->register_framebuffer
>>   ->fb notifier chain calls into fbcon
>> ->fbcon sets up console on new fbi
>>   ->fbi->set_par
>> ->drm_fb_helper_set_par exercises full kms api
>>
>> And because of locking inversion hilarity all of register_framebuffer
>> is done with the console lock held. Which means that the first time on
>> driver load we exercise _all_ the kms code (all probe paths and
>> modeset paths for everything connected) is under the console lock.
>> That means if anything goes belly-up in that big pile of code nothing
>> ever reaches logfiles (and the machine is dead).
>>
>> Usual tactic to debug that is to temporarily remove those console_lock
>> calls to be able to capture backtraces. I'm fed up writing this patch
>> and recompiling kernels. Hence this patch here to add an unsafe,
>> kernel-taining option to do this at runtime.
>>
>> Cc: Jean-Christophe Plagniol-Villard 
>> Cc: Tomi Valkeinen 
>> Cc: linux-fb...@vger.kernel.org
>> Signed-off-by: Daniel Vetter 
> 
> This one was causing me some problems, if I tried to enable
> lockless_register_fb.  It *looks* like it should work, so I'm not
> quite sure what the deal is.  But I'm 110% fan of getting something
> like this working, because console_lock is pretty much the bane of kms
> developer's existence..
> 
> I'll have to debug further on a system where I can see more than the
> bottom three lines of the second to last backtrace..

Any idea if anyone has ever looked at properly fixing this?

 Tomi



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/15] drm/i915: Add CHV PHY LDO power sanity checks

[Daniel Vetter]

On Thu, Aug 27, 2015 at 10:09:37AM +0530, Deepak wrote:
> 
> 
> On 07/09/2015 02:16 AM, ville.syrj...@linux.intel.com wrote:
> >From: Ville Syrjälä 
> >
> >At various points when changing the DPIO lane/phy power states,
> >construct an expected value of the DISPLAY_PHY_STATUS register
> >and compare it with the real thing.
> >
> >To construct the expected value we look at our shadow PHY_CONTROL
> >register value (which should match what we've just written to the
> >hardware), and we also need to look at the actual state of the cmn
> >power wells as a disabled power well causes the relevant LDO status
> >to be reported as 'on' in DISPLAY_PHY_STATUS.
> >
> >When initially powering up the PHY it performs various internal
> >calibrations for which it fully powers up. That means that if we check
> >for the expetected power state immediately upon releasing cmnreset we
> >would get the occasional false positive. But we can of course
> >poll until the expected value appears. It shouldn't be too long so
> >this shouldn't make modesets substantially longer.
> >
> >One extra complication is introduced when we cross the streams, ie.
> >drive port B with pipe B. In this case we trick CL2 (where the DPLL lives)
> >into life by temporaily powering up the lanes in the second channel,
> >and once the pipe is up and runnign we release the lane power override.
> >At that point the power state of CL2 has somehow gotten entangled with
> >the power state of the first channel. That means that constructing the
> >expected DISPLAY_PHY_STATUS value is a bit tricky since based on the
> >lane power states in the second channel, CL2 should also be powered
> >down. But we can use the DPLL enable bit to determine when CL2 should
> >be alive even if the lanes are powered down. However the power state
> >of CL2 isn't actually tied in with the DPLL state, but to the state
> >of the lanes in first channel, so we have to avoid checking the
> >expected state between shutting down the DPLL and powering down
> >the lanes in the first channel. So no calling assert_chv_phy_status()
> >before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(),
> >but after the write is a safe time to check.
> >
> >Signed-off-by: Ville Syrjälä 

Remaining 3 patches pulled into dinq, thanks.
-Daniel

> >---
> >  drivers/gpu/drm/i915/i915_reg.h |   2 +
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 126 
> > +++-
> >  2 files changed, 111 insertions(+), 17 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> >b/drivers/gpu/drm/i915/i915_reg.h
> >index 586a0f7..429105e 100644
> >--- a/drivers/gpu/drm/i915/i915_reg.h
> >+++ b/drivers/gpu/drm/i915/i915_reg.h
> >@@ -2206,6 +2206,8 @@ enum skl_disp_power_wells {
> >  #define   PHY_COM_LANE_RESET_DEASSERT(phy) (1 << (phy))
> >  #define DISPLAY_PHY_STATUS (VLV_DISPLAY_BASE + 0x60104)
> >  #define   PHY_POWERGOOD(phy)   (((phy) == DPIO_PHY0) ? (1<<31) : 
> > (1<<30))
> >+#define   PHY_STATUS_CMN_LDO(phy, ch)   (1 << 
> >(6-(6*(phy)+3*(ch
> >+#define   PHY_STATUS_SPLINE_LDO(phy, ch, spline)(1 << 
> >(8-(6*(phy)+3*(ch)+(spline
> >  /*
> >   * The i830 generation, in LVDS mode, defines P1 as the bit number set 
> > within
> >diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
> >b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >index a1d9676..e6f1b4ee 100644
> >--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> >+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> >@@ -942,6 +942,107 @@ static void vlv_dpio_cmn_power_well_disable(struct 
> >drm_i915_private *dev_priv,
> > vlv_set_power_well(dev_priv, power_well, false);
> >  }
> >+#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
> >+
> >+static struct i915_power_well *lookup_power_well(struct drm_i915_private 
> >*dev_priv,
> >+ int power_well_id)
> >+{
> >+struct i915_power_domains *power_domains = _priv->power_domains;
> >+struct i915_power_well *power_well;
> >+int i;
> >+
> >+for_each_power_well(i, power_well, POWER_DOMAIN_MASK, power_domains) {
> >+if (power_well->data == power_well_id)
> >+return power_well;
> >+}
> >+
> >+return NULL;
> >+}
> >+
> >+#define BITS_SET(val, bits) (((val) & (bits)) == (bits))
> >+
> >+static void assert_chv_phy_status(struct drm_i915_private *dev_priv)
> >+{
> >+struct i915_power_well *cmn_bc =
> >+lookup_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC);
> >+struct i915_power_well *cmn_d =
> >+lookup_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_D);
> >+u32 phy_control = dev_priv->chv_phy_control;
> >+u32 phy_status = 0;
> >+u32 tmp;
> >+
> >+if (cmn_bc->ops->is_enabled(dev_priv, cmn_bc)) {
> >+phy_status |= PHY_POWERGOOD(DPIO_PHY0);
> >+
> >+/* this assumes override is only used to enable lanes */
> >+if 

Re: [Intel-gfx] [PATCH 3/2] drm/i915: Factor out intel_crtc_has_encoders()

[Daniel Vetter]

On Thu, Aug 27, 2015 at 10:29:13AM +0300, Jani Nikula wrote:
> On Wed, 26 Aug 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Make the code mode readable by pulling the "does this crtc have any
> > encoders?" deduction into a separate function.
> >
> > Cc: Maarten Lankhorst 
> > Signed-off-by: Ville Syrjälä 
> 
> Reviewed-by: Jani Nikula 

Both applied to dinq, thanks.
-Daniel

> 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 22 +-
> >  1 file changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9e92915..ac2c2f1 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14855,13 +14855,22 @@ intel_check_plane_mapping(struct intel_crtc *crtc)
> > return true;
> >  }
> >  
> > +static bool intel_crtc_has_encoders(struct intel_crtc *crtc)
> > +{
> > +   struct drm_device *dev = crtc->base.dev;
> > +   struct intel_encoder *encoder;
> > +
> > +   for_each_encoder_on_crtc(dev, >base, encoder)
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> >  static void intel_sanitize_crtc(struct intel_crtc *crtc)
> >  {
> > struct drm_device *dev = crtc->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > -   struct intel_encoder *encoder;
> > u32 reg;
> > -   bool enable;
> >  
> > /* Clear any frame start delays used for debugging left by the BIOS */
> > reg = PIPECONF(crtc->config->cpu_transcoder);
> > @@ -14905,16 +14914,11 @@ static void intel_sanitize_crtc(struct intel_crtc 
> > *crtc)
> >  
> > /* Adjust the state of the output pipe according to whether we
> >  * have active connectors/encoders. */
> > -   enable = false;
> > -   for_each_encoder_on_crtc(dev, >base, encoder) {
> > -   enable = true;
> > -   break;
> > -   }
> > -
> > -   if (!enable)
> > +   if (!intel_crtc_has_encoders(crtc))
> > intel_crtc_disable_noatomic(>base);
> >  
> > if (crtc->active != crtc->base.state->active) {
> > +   struct intel_encoder *encoder;
> >  
> > /* This can happen either due to bugs in the get_hw_state
> >  * functions or because of calls to intel_crtc_disable_noatomic,
> > -- 
> > 2.4.6
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Save sink_count for tracking changes to it

[Jani Nikula]

On Thu, 27 Aug 2015, Sivakumar Thulasimani  
wrote:
> From: "Thulasimani,Sivakumar" 
>
> sink count can change between short pulse hpd hence this patch
> adds a member variable to intel_dp so we can track any changes
> between short pulse interrupts.
>
> Signed-off-by: Sivakumar Thulasimani 

Provided the earlier patch gets a proper explanation,

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_dp.c  |5 ++---
>  drivers/gpu/drm/i915/intel_drv.h |1 +
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 9e4e27d..834f513 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3898,7 +3898,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   struct drm_device *dev = dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   uint8_t rev;
> - uint8_t reg;
>  
>   if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
>   sizeof(intel_dp->dpcd)) < 0)
> @@ -3910,10 +3909,10 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   return false; /* DPCD not present */
>  
>   if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
> - , 1) < 0)
> + _dp->sink_count, 1) < 0)
>   return false;
>  
> - if (!DP_GET_SINK_COUNT(reg))
> + if (!DP_GET_SINK_COUNT(intel_dp->sink_count))
>   return false;
>  
>   /* Check if the panel supports PSR */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 81b7d77..8aca5bb 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -712,6 +712,7 @@ struct intel_dp {
>   enum hdmi_force_audio force_audio;
>   bool limited_color_range;
>   bool color_range_auto;
> + uint8_t sink_count;
>   uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
>   uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
>   uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
> -- 
> 1.7.9.5
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl+: Enable pipe CSC on cursor planes.

[shuang . he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: 
shuang...@intel.com)
Task id: 7280
-Summary-
Platform  Delta  drm-intel-nightly  Series Applied
ILK -1  302/302  301/302
SNB  315/315  315/315
IVB  336/336  336/336
BYT  283/283  283/283
HSW  378/378  378/378
-Detailed-
Platform  Testdrm-intel-nightly  Series 
Applied
*ILK  igt@kms_flip@wf_vblank-vs-modeset-interruptible  PASS(1)  
DMESG_WARN(1)
Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] i915: Set ddi_pll_sel in DP MST path

[Jani Nikula]

On Mon, 31 Aug 2015, Ville Syrjälä  wrote:
> On Mon, Aug 31, 2015 at 11:23:28AM +0300, Ander Conselvan de Oliveira wrote:
>> The DP MST encoder config function never sets ddi_pll_sel, even though
>> its value is programmed in its ->pre_enable() hook. That used to work
>> because a new pipe_config was kzalloc'ed at every modeset, and the value
>> of zero selects the highest clock for the PLL. Starting with the commit
>> below, the value of ddi_pll_sel is preserved through modesets, and since
>> the correct value wasn't properly setup by the MST code, it could lead
>> to warnings and blank screens.
>
> The ddi pll handling is still quite a mess. Every platform does things
> just a bit different to the next guy.
>
> But yeah, looks like HSW/BDW handle the PLL selection for DP from
> the encoder .compute_config() so MST should do the same since it
> (re)computes the main link config for each stream. And SKL and BXT
> handle DP via the .crtc_compute_clock() path, so nothing needed for
> them I suppose.
>
> Reviewed-by: Ville Syrjälä 

Pushed to drm-intel-next-fixes, thanks for the patch and review.

I cherry-picked

commit 840b32b7eda7837db6e0236293f71fc6644dedf8
Author: Ville Syrjälä 
Date:   Tue Aug 11 20:21:46 2015 +0300

drm/i915: Don't use link_bw for PLL setup

from drm-intel-next-queued first to avoid conflicts.

BR,
Jani.


>
>> 
>> commit 8504c74c7ae48b4b8ed1f1c0acf67482a7f45c93
>> Author: Ander Conselvan de Oliveira 
>> Date:   Fri May 15 11:51:50 2015 +0300
>> 
>> drm/i915: Preserve ddi_pll_sel when allocating new pipe_config
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628
>> Cc: sta...@vger.kernel.org
>> Cc: Timo Aaltonen 
>> Cc: Luciano Coelho 
>> Signed-off-by: Ander Conselvan de Oliveira 
>> 
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 2 +-
>>  drivers/gpu/drm/i915/intel_dp_mst.c | 5 +
>>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>>  3 files changed, 7 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 9e90a2b..393aed0 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1190,7 +1190,7 @@ skl_edp_set_pll_config(struct intel_crtc_state 
>> *pipe_config)
>>  pipe_config->dpll_hw_state.ctrl1 = ctrl1;
>>  }
>>  
>> -static void
>> +void
>>  hsw_dp_set_ddi_pll_sel(struct intel_crtc_state *pipe_config)
>>  {
>>  memset(_config->dpll_hw_state, 0,
>> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
>> b/drivers/gpu/drm/i915/intel_dp_mst.c
>> index ebf2054..677d70e 100644
>> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
>> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
>> @@ -33,6 +33,7 @@
>>  static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
>>  struct intel_crtc_state *pipe_config)
>>  {
>> +struct drm_device *dev = encoder->base.dev;
>>  struct intel_dp_mst_encoder *intel_mst = enc_to_mst(>base);
>>  struct intel_digital_port *intel_dig_port = intel_mst->primary;
>>  struct intel_dp *intel_dp = _dig_port->dp;
>> @@ -88,6 +89,10 @@ static bool intel_dp_mst_compute_config(struct 
>> intel_encoder *encoder,
>> _config->dp_m_n);
>>  
>>  pipe_config->dp_m_n.tu = slots;
>> +
>> +if (IS_HASWELL(dev) || IS_BROADWELL(dev))
>> +hsw_dp_set_ddi_pll_sel(pipe_config);
>> +
>>  return true;
>>  
>>  }
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index c61ba47..458f56c 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1209,6 +1209,7 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
>>  void intel_edp_drrs_invalidate(struct drm_device *dev,
>>  unsigned frontbuffer_bits);
>>  void intel_edp_drrs_flush(struct drm_device *dev, unsigned 
>> frontbuffer_bits);
>> +void hsw_dp_set_ddi_pll_sel(struct intel_crtc_state *pipe_config);
>>  
>>  /* intel_dp_mst.c */
>>  int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, 
>> int conn_id);
>> -- 
>> 2.4.3
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/gtt: Avoid calling kcalloc in a loop when allocating temp bitmaps

[Michał Winiarski]

On Mon, Aug 31, 2015 at 07:42:34PM +0100, Chris Wilson wrote:
> On Mon, Aug 31, 2015 at 06:59:40PM +0200, Michał Winiarski wrote:
> > On each call to gen8_alloc_va_range_3lvl we're allocating temporary
> > bitmaps needed for error handling. Unfortunately, when we increase
> > address space size (48b ppgtt) we do additional (512 - 4) calls to
> > kcalloc, increasing latency between exec and actual start of execution
> > on the GPU. Let's just do a single kcalloc and setup proper offsets in
> > an array, we can also drop the size from free_gen8_temp_bitmaps since
> > it's no longer needed.
> > 
> > v2: Use GFP_TEMPORARY to make the allocations reclaimable.
> > 
> > Cc: Chris Wilson 
> > Cc: Mika Kuoppala 
> > Cc: Michel Thierry 
> > Signed-off-by: Michał Winiarski 
> 
> Is there any reason why it remains a 2D array though? Looks like it can
> be reduced to a single block. And why do we allocate a bitmap for the
> whole address space rather than just the range being allocated?

No particular reason, let's try that.
It's not the whole address space... Quite possibly just 1/512 of the whole
address space, as the PUD is handled in gen8_alloc_va_range_4lvl. I guess it was
done to simplify... something, although I can't tell what at this point.
 
> While you may just answer the questions posed, this looks clumsy:

Yup - missed that, I was using temp variable before sending the patch.
-Michał

> 
> > +   *pts = kcalloc(pdpes * BITS_TO_LONGS(I915_PDES),
> > +   sizeof(unsigned long), GFP_TEMPORARY);
> > +   if (!*pts)
> > +   goto err_out;
> > +
> > +   for (i = 0; i < pdpes; i++)
> > +   pts[i] = *pts + i * BITS_TO_LONGS(I915_PDES);
> 
> i..e
> 
> for (i = 1; i < pdpes; i++)
>   pts[i] = pts[0] + i* BITS_TO_LONGS(I915_PDES);
> 
> raises fewer questions.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Fix bookkeeping with TEST_ONLY, v3.

[Jani Nikula]

On Mon, 31 Aug 2015, Maarten Lankhorst  
wrote:
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> In the check only case plane->fb shouldn't be updated, and
> the vblank events should be cleared as on failure.
>
> Changes since v1:
> - Fix -EDEADLK handling of vblank events too.
> - Free state last with CHECK_ONLY.
> Changes since v2:
> - Add comment about freeing crtc_state->event with TEST_ONLY.
>   (Daniel Stone)
>
> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Daniel Stone 

Pushed to our topic/drm-fixes branch, thanks for the patch and review.

BR,
Jani.


> ---
>  drivers/gpu/drm/drm_atomic.c | 39 +++
>  1 file changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index e515261d0a7f..940f80bbf192 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1540,7 +1540,8 @@ retry:
>   copied_props++;
>   }
>  
> - if (obj->type == DRM_MODE_OBJECT_PLANE && count_props) {
> + if (obj->type == DRM_MODE_OBJECT_PLANE && count_props &&
> + !(arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)) {
>   plane = obj_to_plane(obj);
>   plane_mask |= (1 << drm_plane_index(plane));
>   plane->old_fb = plane->fb;
> @@ -1562,10 +1563,11 @@ retry:
>   }
>  
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> + /*
> +  * Unlike commit, check_only does not clean up state.
> +  * Below we call drm_atomic_state_free for it.
> +  */
>   ret = drm_atomic_check_only(state);
> - /* _check_only() does not free state, unlike _commit() */
> - if (!ret)
> - drm_atomic_state_free(state);
>   } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
>   ret = drm_atomic_async_commit(state);
>   } else {
> @@ -1592,25 +1594,30 @@ out:
>   plane->old_fb = NULL;
>   }
>  
> + if (ret && arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> + /*
> +  * TEST_ONLY and PAGE_FLIP_EVENT are mutually exclusive,
> +  * if they weren't, this code should be called on success
> +  * for TEST_ONLY too.
> +  */
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + if (!crtc_state->event)
> + continue;
> +
> + destroy_vblank_event(dev, file_priv,
> +  crtc_state->event);
> + }
> + }
> +
>   if (ret == -EDEADLK) {
>   drm_atomic_state_clear(state);
>   drm_modeset_backoff();
>   goto retry;
>   }
>  
> - if (ret) {
> - if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (!crtc_state->event)
> - continue;
> -
> - destroy_vblank_event(dev, file_priv,
> -  crtc_state->event);
> - }
> - }
> -
> + if (ret || arg->flags & DRM_MODE_ATOMIC_TEST_ONLY)
>   drm_atomic_state_free(state);
> - }
>  
>   drm_modeset_drop_locks();
>   drm_modeset_acquire_fini();
> -- 
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix command parser to validate multiple register access with the same command.

[Daniel Vetter]

On Mon, Aug 31, 2015 at 01:19:47AM +0300, Francisco Jerez wrote:
> Francisco Jerez  writes:
> 
> > Daniel Vetter  writes:
> >
> >> On Mon, Jun 15, 2015 at 02:26:22PM +0300, Ville Syrjälä wrote:
> >>> On Mon, Jun 15, 2015 at 02:18:01PM +0300, Francisco Jerez wrote:
> >>> > Daniel Vetter  writes:
> >>> > 
> >>> > > On Tue, Jun 02, 2015 at 05:36:26PM +0800, Zhigang Gong wrote:
> >>> > >> The patchset LGTM and works well with beignet. The 80%+ performance 
> >>> > >> regression issue in darktable also has been fixed
> >>> > >> after this patchset applied and enable the atomic in L3 at beignet 
> >>> > >> side. So,
> >>> > >> 
> >>> > >> Reviewed-by: Zhigang Gong 
> >>> > >
> >>> > > All three merged.
> >>> > 
> >>> > Thanks Daniel.
> >>> > 
> >>> > > Aside: Dont we need an increment for the cmd parser version for
> >>> > > userspace to be able to detect this?
> >>> > >
> >>> > Yeah, that would be a good idea, patch attached.
> >>> 
> >>> The old version alloweed userspace to write basically any register, the
> >>> new version allows only the whitelisted registers. I don't see how a
> >>> version number bump would help anyone.
> >>
> >> Oops, totally missed the context of patch 1. Jani I think that one's for
> >> you too ...
> >>
> > IMHO the version bump is still useful for userspace to find out whether
> > it can use plain LRIs to write the L3 atomic chicken bits.  It's true
> > that as Ville said it would have been possible for userspace to write
> > the same bits before this series by building a batch specifically
> > crafted to cheat the command parser, but I don't think we want userspace
> > to rely on a command parser bug (e.g. because we may want to back-port
> > the fix to earlier kernel versions).
> >
> Ping.  I cannot use these registers from userspace until the command
> parser version number is bumped.

Queued for -next, thanks for the patch.
-Daniel

> 
> >> Thanks for pointing this out.
> >> -Daniel
> >> -- 
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> http://blog.ffwll.ch
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx




-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix module initialisation, v2.

[Daniel Vetter]

On Mon, Aug 31, 2015 at 03:13:41PM -0700, Matt Roper wrote:
> On Thu, Aug 27, 2015 at 03:15:15PM +0200, Maarten Lankhorst wrote:
> > Set DRIVER_MODESET and DRIVER_ATOMIC by default. The driver is fully atomic.
> > Remove the legacy suspend/resume, to fix a warning introduced by:
> > 
> > "drm: WARN_ON if a modeset driver uses legacy suspend/resume helpers"
> > 
> > and removing the .get_vblank_timestamp reset to NULL. It's a noop without 
> > UMS.
> > 
> > Signed-off-by: Maarten Lankhorst 
> 
> Reviewed-by: Matt Roper 

Review should include the commit message and this commit message doesn't
match v2 at all ... Please rectify (or at least tell me what I should put
there).

Thanks, Daniel

> 
> > ---
> > diff --git a/drivers/gpu/drm/i915/i915_dma.c 
> > b/drivers/gpu/drm/i915/i915_dma.c
> > index 097d4ba0421c..f0eaa6f8826b 100644
> > --- a/drivers/gpu/drm/i915/i915_dma.c
> > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > @@ -364,12 +364,12 @@ static void i915_switcheroo_set_state(struct pci_dev 
> > *pdev, enum vga_switcheroo_
> > dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> > /* i915 resume handler doesn't set to D0 */
> > pci_set_power_state(dev->pdev, PCI_D0);
> > -   i915_resume_legacy(dev);
> > +   i915_resume_switcheroo(dev);
> > dev->switch_power_state = DRM_SWITCH_POWER_ON;
> > } else {
> > pr_err("switched off\n");
> > dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
> > -   i915_suspend_legacy(dev, pmm);
> > +   i915_suspend_switcheroo(dev, pmm);
> > dev->switch_power_state = DRM_SWITCH_POWER_OFF;
> > }
> >  }
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index ce3bd0c713b9..4646fe1a0499 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -679,7 +679,7 @@ static int i915_drm_suspend_late(struct drm_device 
> > *drm_dev, bool hibernation)
> > return 0;
> >  }
> >  
> > -int i915_suspend_legacy(struct drm_device *dev, pm_message_t state)
> > +int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state)
> >  {
> > int error;
> >  
> > @@ -812,7 +812,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
> > return ret;
> >  }
> >  
> > -int i915_resume_legacy(struct drm_device *dev)
> > +int i915_resume_switcheroo(struct drm_device *dev)
> >  {
> > int ret;
> >  
> > @@ -1649,7 +1649,7 @@ static struct drm_driver driver = {
> >  */
> > .driver_features =
> > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM | DRIVER_PRIME |
> > -   DRIVER_RENDER,
> > +   DRIVER_RENDER | DRIVER_MODESET,
> > .load = i915_driver_load,
> > .unload = i915_driver_unload,
> > .open = i915_driver_open,
> > @@ -1658,10 +1658,6 @@ static struct drm_driver driver = {
> > .postclose = i915_driver_postclose,
> > .set_busid = drm_pci_set_busid,
> >  
> > -   /* Used in place of i915_pm_ops for non-DRIVER_MODESET */
> > -   .suspend = i915_suspend_legacy,
> > -   .resume = i915_resume_legacy,
> > -
> >  #if defined(CONFIG_DEBUG_FS)
> > .debugfs_init = i915_debugfs_init,
> > .debugfs_cleanup = i915_debugfs_cleanup,
> > @@ -1704,7 +1700,6 @@ static int __init i915_init(void)
> >  * either the i915.modeset prarameter or by the
> >  * vga_text_mode_force boot option.
> >  */
> > -   driver.driver_features |= DRIVER_MODESET;
> >  
> > if (i915.modeset == 0)
> > driver.driver_features &= ~DRIVER_MODESET;
> > @@ -1715,17 +1710,11 @@ static int __init i915_init(void)
> >  #endif
> >  
> > if (!(driver.driver_features & DRIVER_MODESET)) {
> > -   driver.get_vblank_timestamp = NULL;
> > /* Silently fail loading to not upset userspace. */
> > DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
> > return 0;
> > }
> >  
> > -   /*
> > -* FIXME: Note that we're lying to the DRM core here so that we can get 
> > access
> > -* to the atomic ioctl and the atomic properties.  Only plane 
> > operations on
> > -* a single CRTC will actually work.
> > -*/
> > if (i915.nuclear_pageflip)
> > driver.driver_features |= DRIVER_ATOMIC;
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8c938451a05e..5c2541ddf212 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2607,8 +2607,8 @@ struct drm_i915_cmd_table {
> >  extern const struct drm_ioctl_desc i915_ioctls[];
> >  extern int i915_max_ioctl;
> >  
> > -extern int i915_suspend_legacy(struct drm_device *dev, pm_message_t state);
> > -extern int i915_resume_legacy(struct drm_device *dev);
> > +extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t 
> > state);
> > +extern int i915_resume_switcheroo(struct drm_device *dev);

Re: [Intel-gfx] [PATCH 1/4] drm/i915: read dpcd 0 - 12 & link_status always

[Jani Nikula]

On Thu, 27 Aug 2015, Sivakumar Thulasimani  
wrote:
> From: "Thulasimani,Sivakumar" 
>
> Compliance requires the driver to read dpcd register 0 to 12 and
> registers 0x200 to 0x205 to be read always.
> Current code performs dpcd read for short pulse interrupts only
> if the sink is enabled. This patch forces read for link status
> and registers 0 to 12.

While this seems a bit silly from the driver perspective, I don't see it
doing much harm either.

Note that We do read dpcd 0 to 14 no matter what the spec says.

Reviewed-by: Jani Nikula 

>
> Signed-off-by: Sivakumar Thulasimani 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 8a66a44..76561e0 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4374,12 +4374,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>  
>   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  
> - if (!intel_encoder->base.crtc)
> - return;
> -
> - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> - return;
> -
>   /* Try to read receiver status if the link appears to be up */
>   if (!intel_dp_get_link_status(intel_dp, link_status)) {
>   return;
> @@ -4390,6 +4384,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>   return;
>   }
>  
> + if (!intel_encoder->base.crtc)
> + return;
> +
> + if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> + return;
> +
>   /* Try to read the source of the interrupt */
>   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
>   intel_dp_get_sink_irq(intel_dp, _irq_vector)) {
> -- 
> 1.7.9.5
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: force full detect on sink count change

[Jani Nikula]

On Thu, 27 Aug 2015, Sivakumar Thulasimani  
wrote:
> From: "Thulasimani,Sivakumar" 
>
> This patch checks for changes in sink count between short pulse
> hpds and forces full detect when there is a change.
>
> This will allow both detection of hotplug and unplug of panels
> through dongles that give only short pulse for such events.
>
> v2: changed variable type from u8 to bool (Jani)
> return immediately if perform_full_detect is set(Siva)

The general idea LGTM, however see below.

>
> Signed-off-by: Sivakumar Thulasimani 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   27 ++-
>  1 file changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 834f513..279e52c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4370,26 +4370,39 @@ go_again:
>   *  4. Check link status on receipt of hot-plug interrupt
>   */
>  static void
> -intel_dp_check_link_status(struct intel_dp *intel_dp)
> +intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
> *perform_full_detect)
>  {
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
>   struct intel_crtc *crtc =
>   to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
>   u8 sink_irq_vector;
> + u8 old_sink_count = intel_dp->sink_count;
> + bool ret;
>   u8 link_status[DP_LINK_STATUS_SIZE];
>  
>   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  
> + *perform_full_detect = false;
> +
>   /* Try to read receiver status if the link appears to be up */
>   if (!intel_dp_get_link_status(intel_dp, link_status)) {
>   return;
>   }
>  
> - /* Now read the DPCD to see if it's actually running */
> - if (!intel_dp_get_dpcd(intel_dp)) {
> + /* Now read the DPCD to see if it's actually running
> +  * Don't return immediately if dpcd read failed,
> +  * if sink count was 1 and dpcd read failed we need
> +  * to do full detection
> +  */
> + ret = intel_dp_get_dpcd(intel_dp);
> +
> + if (old_sink_count != intel_dp->sink_count)
> + *perform_full_detect = true;

The point I was trying to make earlier is that how can you trust
intel_dp->sink_count if intel_dp_get_dpcd failed? You don't know where
it failed, and ->sink_count may or may not have changed. Maybe it has
changed for real but you didn't have a chance to read it just yet.

> +
> + /* No need to proceed if we are going to do full detect */
> + if (!ret || *perform_full_detect)
>   return;
> - }

So if you're returning because of !ret, *perform_full_detect may be true
or false, you don't know. I'd like the code to be explicit about what
you want the caller to do when intel_dp_get_dpcd returns false, full
detect or not.

BR,
Jani.

>  
>   if (!intel_encoder->base.crtc)
>   return;
> @@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>   }
>  
>   if (!intel_dp->is_mst) {
> + bool full_detect;
>   /*
>* we'll check the link status via the normal hot plug 
> path later -
>* but for short hpds we should check it now
>*/
>   drm_modeset_lock(>mode_config.connection_mutex, 
> NULL);
> - intel_dp_check_link_status(intel_dp);
> + intel_dp_check_link_status(intel_dp, _detect);
>   drm_modeset_unlock(>mode_config.connection_mutex);
> +
> + if (full_detect)
> + goto put_power;
>   }
>   }
>  
> -- 
> 1.7.9.5
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/2] drm/i915: Also record time difference if vblank evasion fails, v2.

[Maarten Lankhorst]

This makes the error message slightly more useful.

Changes since v1:
- Use ktime_get() while irqs are still disabled. (vsyrjala)

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 63f0d5850cdf..b0c3a3af7ed2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -563,6 +563,8 @@ struct intel_crtc {
int scanline_offset;
 
unsigned start_vbl_count;
+   ktime_t start_vbl_time;
+
struct intel_crtc_atomic_commit atomic;
 
/* scalers available on this crtc */
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 63fba42be2cf..9387af5ef1b8 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -134,6 +134,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
 
drm_crtc_vblank_put(>base);
 
+   crtc->start_vbl_time = ktime_get();
crtc->start_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
 
trace_i915_pipe_update_vblank_evaded(crtc, min, max,
@@ -154,14 +155,16 @@ void intel_pipe_update_end(struct intel_crtc *crtc)
struct drm_device *dev = crtc->base.dev;
enum pipe pipe = crtc->pipe;
u32 end_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
+   ktime_t end_vbl_time = ktime_get();
 
trace_i915_pipe_update_end(crtc, end_vbl_count);
 
local_irq_enable();
 
if (crtc->start_vbl_count && crtc->start_vbl_count != end_vbl_count)
-   DRM_ERROR("Atomic update failure on pipe %c (start=%u 
end=%u)\n",
- pipe_name(pipe), crtc->start_vbl_count, 
end_vbl_count);
+   DRM_ERROR("Atomic update failure on pipe %c (start=%u end=%u) 
time %lld us\n",
+ pipe_name(pipe), crtc->start_vbl_count, end_vbl_count,
+ ktime_us_delta(end_vbl_time, crtc->start_vbl_time));
 }
 
 static void

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: force full detect on sink count change

[Sivakumar Thulasimani]

On 9/1/2015 4:12 PM, Jani Nikula wrote:

On Thu, 27 Aug 2015, Sivakumar Thulasimani  
wrote:

From: "Thulasimani,Sivakumar" 

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

v2: changed variable type from u8 to bool (Jani)
 return immediately if perform_full_detect is set(Siva)

The general idea LGTM, however see below.


Signed-off-by: Sivakumar Thulasimani 
---
  drivers/gpu/drm/i915/intel_dp.c |   27 ++-
  1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..279e52c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,39 @@ go_again:
   *  4. Check link status on receipt of hot-plug interrupt
   */
  static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)
  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp->sink_count;
+   bool ret;
u8 link_status[DP_LINK_STATUS_SIZE];
  
  	WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
  
+	*perform_full_detect = false;

+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
  
-	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   /* Now read the DPCD to see if it's actually running
+* Don't return immediately if dpcd read failed,
+* if sink count was 1 and dpcd read failed we need
+* to do full detection
+*/
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp->sink_count)
+   *perform_full_detect = true;

The point I was trying to make earlier is that how can you trust
intel_dp->sink_count if intel_dp_get_dpcd failed? You don't know where
it failed, and ->sink_count may or may not have changed. Maybe it has
changed for real but you didn't have a chance to read it just yet.


+
+   /* No need to proceed if we are going to do full detect */
+   if (!ret || *perform_full_detect)
return;
-   }

So if you're returning because of !ret, *perform_full_detect may be true
or false, you don't know. I'd like the code to be explicit about what
you want the caller to do when intel_dp_get_dpcd returns false, full
detect or not.

BR,
Jani.
the idea i had in mind was if intel_dp_get_dpcd failed we should do a 
full detect.


my assumption here was that sink_count would be zero so it would take care
of this, but now that it seems to be a wrong assumption how about the 
following code ?

this makes it explicit that if dpcd read failed we will do full detect.

+   if ((old_sink_count != intel_dp->sink_count) || !ret)
+   *perform_full_detect = true;

+
+   /* No need to proceed if we are going to do full detect */
+   if (*perform_full_detect)
return;



  
  	if (!intel_encoder->base.crtc)

return;
@@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp->is_mst) {

+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(>mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, _detect);
drm_modeset_unlock(>mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
  
--

1.7.9.5



--
regards,
Sivakumar

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

On 9/1/2015 3:59 PM, Jani Nikula wrote:

On Thu, 27 Aug 2015, Sivakumar Thulasimani  
wrote:

From: "Thulasimani,Sivakumar" 

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

This makes sense.

I'm scared this may break something, if there are displays/adapters out
there that don't set sink count properly. I guess only one way to find
out... And this might actually fix something else.


Here is a table of possible values and scenarios

sink_count  downstream_port
 present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Do you think you handle this last case properly now? Previously we'd
return with "connected" at the sink count check, but now we'll go for
the "pke ddc gently" phase.

See below.


v2: moved out crtc enabled checks to prior patch(Jani)

Signed-off-by: Sivakumar Thulasimani 
---
  drivers/gpu/drm/i915/intel_dp.c |   21 -
  1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76561e0..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
+   uint8_t reg;
  
  	if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,

sizeof(intel_dp->dpcd)) < 0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
  
+	if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,

+   , 1) < 0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
  
-	/* If we're HPD-aware, SINK_COUNT changes dynamically */

-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
-   intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
-   , 1) < 0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-

Why do we proceed here if we know that we have sink count > 0 and we
have a downstream port present? Admittedly I'm not sure I understand (or
remember) why we had this logic in the first place...

BR,
Jani.
based on what little i can dig up, we proceed in case of dongles to 
check if the

display is CRT or not.
if edid read succeeded, it is DP or any display with proper edid to work 
with.

If edid read failed, then it could be CRT, without edid

we can make it work with a fake edid, but it seems current code just
sets it as connector_status_unknown and ignores the display


/* If no HPD, poke DDC gently */
if (drm_probe_ddc(_dp->aux.ddc))
return connector_status_connected;
--
1.7.9.5



--
regards,
Sivakumar

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: force full detect on sink count change

[Jani Nikula]

On Tue, 01 Sep 2015, Sivakumar Thulasimani  
wrote:
> On 9/1/2015 4:12 PM, Jani Nikula wrote:
>> On Thu, 27 Aug 2015, Sivakumar Thulasimani  
>> wrote:
>>> From: "Thulasimani,Sivakumar" 
>>>
>>> This patch checks for changes in sink count between short pulse
>>> hpds and forces full detect when there is a change.
>>>
>>> This will allow both detection of hotplug and unplug of panels
>>> through dongles that give only short pulse for such events.
>>>
>>> v2: changed variable type from u8 to bool (Jani)
>>>  return immediately if perform_full_detect is set(Siva)
>> The general idea LGTM, however see below.
>>
>>> Signed-off-by: Sivakumar Thulasimani 
>>> ---
>>>   drivers/gpu/drm/i915/intel_dp.c |   27 ++-
>>>   1 file changed, 22 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index 834f513..279e52c 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -4370,26 +4370,39 @@ go_again:
>>>*  4. Check link status on receipt of hot-plug interrupt
>>>*/
>>>   static void
>>> -intel_dp_check_link_status(struct intel_dp *intel_dp)
>>> +intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
>>> *perform_full_detect)
>>>   {
>>> struct drm_device *dev = intel_dp_to_dev(intel_dp);
>>> struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
>>> struct intel_crtc *crtc =
>>> to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
>>> u8 sink_irq_vector;
>>> +   u8 old_sink_count = intel_dp->sink_count;
>>> +   bool ret;
>>> u8 link_status[DP_LINK_STATUS_SIZE];
>>>   
>>> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>>>   
>>> +   *perform_full_detect = false;
>>> +
>>> /* Try to read receiver status if the link appears to be up */
>>> if (!intel_dp_get_link_status(intel_dp, link_status)) {
>>> return;
>>> }
>>>   
>>> -   /* Now read the DPCD to see if it's actually running */
>>> -   if (!intel_dp_get_dpcd(intel_dp)) {
>>> +   /* Now read the DPCD to see if it's actually running
>>> +* Don't return immediately if dpcd read failed,
>>> +* if sink count was 1 and dpcd read failed we need
>>> +* to do full detection
>>> +*/
>>> +   ret = intel_dp_get_dpcd(intel_dp);
>>> +
>>> +   if (old_sink_count != intel_dp->sink_count)
>>> +   *perform_full_detect = true;
>> The point I was trying to make earlier is that how can you trust
>> intel_dp->sink_count if intel_dp_get_dpcd failed? You don't know where
>> it failed, and ->sink_count may or may not have changed. Maybe it has
>> changed for real but you didn't have a chance to read it just yet.
>>
>>> +
>>> +   /* No need to proceed if we are going to do full detect */
>>> +   if (!ret || *perform_full_detect)
>>> return;
>>> -   }
>> So if you're returning because of !ret, *perform_full_detect may be true
>> or false, you don't know. I'd like the code to be explicit about what
>> you want the caller to do when intel_dp_get_dpcd returns false, full
>> detect or not.
>>
>> BR,
>> Jani.
> the idea i had in mind was if intel_dp_get_dpcd failed we should do a 
> full detect.
>
> my assumption here was that sink_count would be zero so it would take care
> of this, but now that it seems to be a wrong assumption how about the 
> following code ?
> this makes it explicit that if dpcd read failed we will do full detect.
>
> + if ((old_sink_count != intel_dp->sink_count) || !ret)
> + *perform_full_detect = true;
>
> +
> + /* No need to proceed if we are going to do full detect */
> + if (*perform_full_detect)
>   return;

Ok by me.

Jani.



>
>>
>>>   
>>> if (!intel_encoder->base.crtc)
>>> return;
>>> @@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
>>> *intel_dig_port, bool long_hpd)
>>> }
>>>   
>>> if (!intel_dp->is_mst) {
>>> +   bool full_detect;
>>> /*
>>>  * we'll check the link status via the normal hot plug 
>>> path later -
>>>  * but for short hpds we should check it now
>>>  */
>>> drm_modeset_lock(>mode_config.connection_mutex, 
>>> NULL);
>>> -   intel_dp_check_link_status(intel_dp);
>>> +   intel_dp_check_link_status(intel_dp, _detect);
>>> drm_modeset_unlock(>mode_config.connection_mutex);
>>> +
>>> +   if (full_detect)
>>> +   goto put_power;
>>> }
>>> }
>>>   
>>> -- 
>>> 1.7.9.5
>>>
>
> -- 
> regards,
> Sivakumar
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing 

Re: [Intel-gfx] [PATCH 02/16] drm/i915: fix the FBC work allocation failure path

[Ville Syrjälä]

On Tue, Sep 01, 2015 at 12:07:01PM +0200, Daniel Vetter wrote:
> On Fri, Aug 28, 2015 at 11:50:08AM -0300, Paulo Zanoni wrote:
> > 2015-08-28 11:20 GMT-03:00 Ville Syrjälä :
> > > On Fri, Aug 14, 2015 at 06:34:07PM -0300, Paulo Zanoni wrote:
> > >> Always update the currrent crtc, fb and vertical offset after calling
> > >> enable_fbc. We were forgetting to do so along the failure paths when
> > >> enabling fbc synchronously. Fix this with a new helper to enable_fbc()
> > >> and update the state simultaneously.
> > >>
> > >> v2: Improve commit message (Chris).
> > >>
> > >> Signed-off-by: Paulo Zanoni 
> > >> ---
> > >>  drivers/gpu/drm/i915/intel_fbc.c | 27 +--
> > >>  1 file changed, 17 insertions(+), 10 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> > >> b/drivers/gpu/drm/i915/intel_fbc.c
> > >> index c97aba2..fa9b004 100644
> > >> --- a/drivers/gpu/drm/i915/intel_fbc.c
> > >> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> > >> @@ -308,6 +308,18 @@ bool intel_fbc_enabled(struct drm_i915_private 
> > >> *dev_priv)
> > >>   return dev_priv->fbc.enabled;
> > >>  }
> > >>
> > >> +static void intel_fbc_enable(struct intel_crtc *crtc,
> > >> +  struct drm_framebuffer *fb)
> > >
> > > fb could be const
> > 
> > I guess a lot of things could be constified, if we decide to do this.
> 
> Personally I like const on .data (especially vfunc tables since those are
> nice to create exploits if they're writable and you can get at them). And
> for core functions/vfuncs where the const has a semantic meaning.
> Otherwise I personally don't see to much value in sprinkling const all
> over.

I especially like making display mode, state, etc. structs const to make
it clear which functions can change them and which can't. IMO
drm_framebuffer could use the same treatment.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix module initialisation, v2.

[Maarten Lankhorst]

Op 01-09-15 om 12:12 schreef Daniel Vetter:
> On Mon, Aug 31, 2015 at 03:13:41PM -0700, Matt Roper wrote:
>> On Thu, Aug 27, 2015 at 03:15:15PM +0200, Maarten Lankhorst wrote:
>>> Set DRIVER_MODESET and DRIVER_ATOMIC by default. The driver is fully atomic.
>>> Remove the legacy suspend/resume, to fix a warning introduced by:
>>>
>>> "drm: WARN_ON if a modeset driver uses legacy suspend/resume helpers"
>>>
>>> and removing the .get_vblank_timestamp reset to NULL. It's a noop without 
>>> UMS.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>> Reviewed-by: Matt Roper 
> Review should include the commit message and this commit message doesn't
> match v2 at all ... Please rectify (or at least tell me what I should put
> there).
>
Oops..

The driver doesn't support UMS any more, so set DRIVER_MODESET by default,
remove the legacy s/r callbacks, and rename the s/r functions to make it more 
clear
they're only in use by switcheroo now.

Also remove an obsolete comment about atomic. Normal updates are supported only
async updates aren't yet.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] drm: Add a non-locking version of drm_kms_helper_poll_enable().

[Egbert Eich]

Lukas Wunner writes:
 > Hi Egbert,
 > 
 > On Wed, Sep 02, 2015 at 12:10:19AM +0200, Egbert Eich wrote:
 > > Lukas Wunner writes:
 > >  > On Tue, Sep 01, 2015 at 10:21:32PM +0200, Egbert Eich wrote:
 > >  > > drm_kms_helper_poll_enable() was converted to lock the mode_config
 > >  > > mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
 > >  > > ("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").
 > >  > > 
 > >  > > This disregarded the cases where this function is called from a 
 > > context
 > >  > > where this mutex is already locked.
 > >  > 
 > >  > Which ones would that be?
 > > 
 > > Have you missed the next patch in the series?
 > 
 > Sorry, I should have asked more precisely: Is this the only one?
 > If so it may make sense to modify i915_hotplug_work_func or
 > intel_hpd_irq_storm_disable instead.
 > 

The non-locking version existed before. I've just exported it so it cah
be used by drivers.
Moreover this is a helper function - why should it be restricted to 
callers which don't have the mode_config mutex grabbed?
I could be talked into changing the log message.

Egbert.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 1/3] drm/i915: Roll intel_crtc->atomic into intel_crtc_state

[Maarten Lankhorst]

Op 01-09-15 om 17:48 schreef Ville Syrjälä:
> On Tue, Sep 01, 2015 at 08:30:05AM -0700, Matt Roper wrote:
>> On Tue, Sep 01, 2015 at 07:24:19AM +0200, Maarten Lankhorst wrote:
>>> Op 29-08-15 om 01:57 schreef Matt Roper:
 Way back at the beginning of i915's atomic conversion I added
 intel_crtc->atomic as a temporary dumping ground for "stuff to do
 outside vblank evasion" flags since CRTC states weren't properly wired
 up and tracked at that time.  We've had proper CRTC state tracking for a
 while now, so there's really no reason for this hack to continue to
 exist.  Moving forward we want to store intermediate crtc/plane state
 data for modesets in addition to the final state, so moving these fields
 into the proper state object allows us to properly compute them for both
 the intermediate and final state.

 Signed-off-by: Matt Roper 
 ---
>>> Can I shoot this patch down? It's better to add a field 'wm_changed'
>>> to the crtc_state, which gets reset to false for each crtc_state
>>> duplication. It's needed for checking if a cs pageflip can be done for
>>> atomic. It would remove the duplication of some checks there.
>>>
>>> The other atomic state members will die soon. I already have some
>>> patches to achieve that. :)
>>>
>>> I'm not sure if an intermediate state is a good idea. Any code that
>>> disables a crtc should only be looking at the old state.
>>> pre_plane_update runs all stuff in preparation for disabling planes,
>>> while post_plane_update runs everything needed for enabling planes. So
>>> no need to split it up I think, maybe put in some intermediate
>>> watermarks in intel_atomic_state, but no need for a full crtc_state.
>> Well, the intermediate state stuff was requested by Ville in response to
>> my watermark series, so I posted these patches as an RFC to make sure I
>> was understanding what he was looking for properly.
>>
>> Ville, can you comment?
> My opinion is that the current "disable is special" way of doing things
> is quite horrible. For one it makes it really hard to reason about what
> happens to a plane or crtc during the modeset. It's not just off->on,
> on->off, or same->same, but can be on->off->on. With the intermediate
> state in place, there can only be one transition, so really easy to
> think about what's going on.
pre_plane_update deals with all stuff related to disabling planes, while 
post_plane_update deals with changes after enabling.

If the crtc goes from on -> off only you could just hammer in the final values 
after the disable.

While for off->on or on->off->on you can put in the final values in 
.crtc_enable before lighting the pipe. I don't see why wm's would need more 
transitions.
> It'll also mean don't have to sprinkle silly wm update calls all over
> the modeset path. They will just get updated in response to the plane
> state changes. Same for IPS/FBC etc.
IPS and FBC are already calculated correctly in response to modesets.

~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Rob Clark]

On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen  wrote:
>
>
> On 25/08/15 22:24, Rob Clark wrote:
>> On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  
>> wrote:
>>> When the usual fbcon legacy options are enabled we have
>>> ->register_framebuffer
>>>   ->fb notifier chain calls into fbcon
>>> ->fbcon sets up console on new fbi
>>>   ->fbi->set_par
>>> ->drm_fb_helper_set_par exercises full kms api
>>>
>>> And because of locking inversion hilarity all of register_framebuffer
>>> is done with the console lock held. Which means that the first time on
>>> driver load we exercise _all_ the kms code (all probe paths and
>>> modeset paths for everything connected) is under the console lock.
>>> That means if anything goes belly-up in that big pile of code nothing
>>> ever reaches logfiles (and the machine is dead).
>>>
>>> Usual tactic to debug that is to temporarily remove those console_lock
>>> calls to be able to capture backtraces. I'm fed up writing this patch
>>> and recompiling kernels. Hence this patch here to add an unsafe,
>>> kernel-taining option to do this at runtime.
>>>
>>> Cc: Jean-Christophe Plagniol-Villard 
>>> Cc: Tomi Valkeinen 
>>> Cc: linux-fb...@vger.kernel.org
>>> Signed-off-by: Daniel Vetter 
>>
>> This one was causing me some problems, if I tried to enable
>> lockless_register_fb.  It *looks* like it should work, so I'm not
>> quite sure what the deal is.  But I'm 110% fan of getting something
>> like this working, because console_lock is pretty much the bane of kms
>> developer's existence..
>>
>> I'll have to debug further on a system where I can see more than the
>> bottom three lines of the second to last backtrace..
>
> Any idea if anyone has ever looked at properly fixing this?

I hadn't had a chance to look at it further yet..  I think Daniel
claimed it worked for him, but he was probably on intel-next, where I
was on drm-next at the time which seemed to be having some unrelated
i915 issues (when I was trying to debug atomic fb-helper patches).  So
can't really say that the issue I had was actually related to this
patch.  I'll try again later this week or next, when hopefully i915 in
drm-next is in better shape..

BR,
-R

>  Tomi
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Rob Clark]

On Tue, Sep 1, 2015 at 10:41 AM, Tomi Valkeinen  wrote:
>
>
> On 01/09/15 17:34, Rob Clark wrote:
>> On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen  wrote:
>>>
>>>
>>> On 25/08/15 22:24, Rob Clark wrote:
 On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  
 wrote:
> When the usual fbcon legacy options are enabled we have
> ->register_framebuffer
>   ->fb notifier chain calls into fbcon
> ->fbcon sets up console on new fbi
>   ->fbi->set_par
> ->drm_fb_helper_set_par exercises full kms api
>
> And because of locking inversion hilarity all of register_framebuffer
> is done with the console lock held. Which means that the first time on
> driver load we exercise _all_ the kms code (all probe paths and
> modeset paths for everything connected) is under the console lock.
> That means if anything goes belly-up in that big pile of code nothing
> ever reaches logfiles (and the machine is dead).
>
> Usual tactic to debug that is to temporarily remove those console_lock
> calls to be able to capture backtraces. I'm fed up writing this patch
> and recompiling kernels. Hence this patch here to add an unsafe,
> kernel-taining option to do this at runtime.
>
> Cc: Jean-Christophe Plagniol-Villard 
> Cc: Tomi Valkeinen 
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Daniel Vetter 

 This one was causing me some problems, if I tried to enable
 lockless_register_fb.  It *looks* like it should work, so I'm not
 quite sure what the deal is.  But I'm 110% fan of getting something
 like this working, because console_lock is pretty much the bane of kms
 developer's existence..

 I'll have to debug further on a system where I can see more than the
 bottom three lines of the second to last backtrace..
>>>
>>> Any idea if anyone has ever looked at properly fixing this?
>>
>> I hadn't had a chance to look at it further yet..  I think Daniel
>> claimed it worked for him, but he was probably on intel-next, where I
>> was on drm-next at the time which seemed to be having some unrelated
>> i915 issues (when I was trying to debug atomic fb-helper patches).  So
>> can't really say that the issue I had was actually related to this
>> patch.  I'll try again later this week or next, when hopefully i915 in
>> drm-next is in better shape..
>
> Oh, I didn't mean this patch, but the whole console lock in general.
> I've also banged my head to a wall because of it =).

oh, not sure.. every time I've started looking closer at
console/console_lock I run away screaming..  I guess if it were
possible to push the lock down further so only drivers that needed the
lock (presumably serial/net/etc) could take it, that would be nice..
but not sure I am that brave..

BR,
-R

>  Tomi
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Tomi Valkeinen]

On 01/09/15 17:34, Rob Clark wrote:
> On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen  wrote:
>>
>>
>> On 25/08/15 22:24, Rob Clark wrote:
>>> On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  
>>> wrote:
 When the usual fbcon legacy options are enabled we have
 ->register_framebuffer
   ->fb notifier chain calls into fbcon
 ->fbcon sets up console on new fbi
   ->fbi->set_par
 ->drm_fb_helper_set_par exercises full kms api

 And because of locking inversion hilarity all of register_framebuffer
 is done with the console lock held. Which means that the first time on
 driver load we exercise _all_ the kms code (all probe paths and
 modeset paths for everything connected) is under the console lock.
 That means if anything goes belly-up in that big pile of code nothing
 ever reaches logfiles (and the machine is dead).

 Usual tactic to debug that is to temporarily remove those console_lock
 calls to be able to capture backtraces. I'm fed up writing this patch
 and recompiling kernels. Hence this patch here to add an unsafe,
 kernel-taining option to do this at runtime.

 Cc: Jean-Christophe Plagniol-Villard 
 Cc: Tomi Valkeinen 
 Cc: linux-fb...@vger.kernel.org
 Signed-off-by: Daniel Vetter 
>>>
>>> This one was causing me some problems, if I tried to enable
>>> lockless_register_fb.  It *looks* like it should work, so I'm not
>>> quite sure what the deal is.  But I'm 110% fan of getting something
>>> like this working, because console_lock is pretty much the bane of kms
>>> developer's existence..
>>>
>>> I'll have to debug further on a system where I can see more than the
>>> bottom three lines of the second to last backtrace..
>>
>> Any idea if anyone has ever looked at properly fixing this?
> 
> I hadn't had a chance to look at it further yet..  I think Daniel
> claimed it worked for him, but he was probably on intel-next, where I
> was on drm-next at the time which seemed to be having some unrelated
> i915 issues (when I was trying to debug atomic fb-helper patches).  So
> can't really say that the issue I had was actually related to this
> patch.  I'll try again later this week or next, when hopefully i915 in
> drm-next is in better shape..

Oh, I didn't mean this patch, but the whole console lock in general.
I've also banged my head to a wall because of it =).

 Tomi



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

On 9/1/2015 6:45 PM, Jani Nikula wrote:

On Tue, 01 Sep 2015, Sivakumar Thulasimani  
wrote:

On 9/1/2015 3:59 PM, Jani Nikula wrote:

On Thu, 27 Aug 2015, Sivakumar Thulasimani  
wrote:

From: "Thulasimani,Sivakumar" 

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

This makes sense.

I'm scared this may break something, if there are displays/adapters out
there that don't set sink count properly. I guess only one way to find
out... And this might actually fix something else.


Here is a table of possible values and scenarios

sink_count  downstream_port
  present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Do you think you handle this last case properly now? Previously we'd
return with "connected" at the sink count check, but now we'll go for
the "pke ddc gently" phase.

See below.


v2: moved out crtc enabled checks to prior patch(Jani)

Signed-off-by: Sivakumar Thulasimani 
---
   drivers/gpu/drm/i915/intel_dp.c |   21 -
   1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76561e0..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
+   uint8_t reg;
   
   	if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,

sizeof(intel_dp->dpcd)) < 0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
   
+	if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,

+   , 1) < 0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
   
-	/* If we're HPD-aware, SINK_COUNT changes dynamically */

-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
-   intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
-   , 1) < 0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-

Why do we proceed here if we know that we have sink count > 0 and we
have a downstream port present? Admittedly I'm not sure I understand (or
remember) why we had this logic in the first place...

BR,
Jani.

based on what little i can dig up, we proceed in case of dongles to
check if the
display is CRT or not.
if edid read succeeded, it is DP or any display with proper edid to work
with.
If edid read failed, then it could be CRT, without edid

My point is, with the current code, if we have downstream port present
and sink count > 0 and the first downsteam port supports hpd, we'll
directly say status is connected. The hpd check may be bogus, but we
still won't go probing ddc on them.

With your patch, we'd always do the ddc probe if there is a downstream
port present and the sink count > 0.

BR,
Jani.
understood, will check once by adding the old check if hpd supported 
downstream

is present and share new patch.




we can make it work with a fake edid, but it seems current code just
sets it as connector_status_unknown and ignores the display


/* If no HPD, poke DDC gently */
if (drm_probe_ddc(_dp->aux.ddc))
return connector_status_connected;
--
1.7.9.5


--
regards,
Sivakumar



--
regards,
Sivakumar

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [BXT MIPI PATCH v3 05/14] drm/i915/bxt: DSI encoder support in CRTC modeset

[Uma Shankar]

From: Shashank Sharma 

SKL and BXT qualifies the HAS_DDI() check, and hence haswell
modeset functions are re-used for modeset sequence. But DDI
interface doesn't include support for DSI.
This patch adds:
1. cases for DSI encoder, in those modeset functions and allows
   a CRTC modeset
2. Adds call to pre_pll enabled from CRTC modeset function. Nothing
   needs to be done as such in CRTC for DSI encoder, as PLL, clock
   and and transcoder programming will be taken care in encoder's
   pre_enable and pre_pll_enable function.

v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI
encoder like DSI for platforms having HAS_DDI as true.

v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid
encoder.

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/intel_ddi.c  |   29 -
 drivers/gpu/drm/i915/intel_display.c  |   19 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c   |1 +
 drivers/gpu/drm/i915/intel_opregion.c |3 ++-
 5 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fd1de45..78d31c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -142,6 +142,7 @@ enum plane {
 #define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) + 'A')
 
 enum port {
+   PORT_INVALID = -1,
PORT_A = 0,
PORT_B,
PORT_C,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cacb07b..5d5aad2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -227,6 +227,10 @@ static void ddi_get_encoder_port(struct intel_encoder 
*intel_encoder,
} else if (type == INTEL_OUTPUT_ANALOG) {
*dig_port = NULL;
*port = PORT_E;
+   } else if (type == INTEL_OUTPUT_DSI) {
+   *dig_port = NULL;
+   *port = PORT_INVALID;
+   DRM_DEBUG_KMS("Encoder type: DSI. Returning...\n");
} else {
DRM_ERROR("Invalid DDI encoder type %d\n", type);
BUG();
@@ -392,6 +396,11 @@ void intel_prepare_ddi(struct drm_device *dev)
 
ddi_get_encoder_port(intel_encoder, _dig_port, );
 
+   if (port == PORT_INVALID) {
+   WARN_ON(1);
+   continue;
+   }
+
if (visited[port])
continue;
 
@@ -980,6 +989,8 @@ static void bxt_ddi_clock_get(struct intel_encoder *encoder,
enum port port = intel_ddi_get_encoder_port(encoder);
uint32_t dpll = port;
 
+   WARN_ON(port == PORT_INVALID);
+
pipe_config->port_clock =
bxt_calc_pll_link(dev_priv, dpll);
 
@@ -1572,6 +1583,8 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
int type = intel_encoder->type;
uint32_t temp;
 
+   WARN_ON(port == PORT_INVALID);
+
/* Enable TRANS_DDI_FUNC_CTL for the pipe to work in HDMI mode */
temp = TRANS_DDI_FUNC_ENABLE;
temp |= TRANS_DDI_SELECT_PORT(port);
@@ -1684,6 +1697,8 @@ bool intel_ddi_connector_get_hw_state(struct 
intel_connector *intel_connector)
enum intel_display_power_domain power_domain;
uint32_t tmp;
 
+   WARN_ON(port == PORT_INVALID);
+
power_domain = intel_display_port_power_domain(intel_encoder);
if (!intel_display_power_is_enabled(dev_priv, power_domain))
return false;
@@ -1730,6 +1745,8 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
u32 tmp;
int i;
 
+   WARN_ON(port == PORT_INVALID);
+
power_domain = intel_display_port_power_domain(encoder);
if (!intel_display_power_is_enabled(dev_priv, power_domain))
return false;
@@ -1779,11 +1796,14 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
*encoder,
 void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc)
 {
struct drm_crtc *crtc = _crtc->base;
-   struct drm_i915_private *dev_priv = crtc->dev->dev_private;
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
enum port port = intel_ddi_get_encoder_port(intel_encoder);
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
 
+   WARN_ON(port == PORT_INVALID);
+
if (cpu_transcoder != TRANSCODER_EDP)
I915_WRITE(TRANS_CLK_SEL(cpu_transcoder),
   TRANS_CLK_SEL_PORT(port));
@@ -1870,6 +1890,8 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
int type = intel_encoder->type;
int hdmi_level;
 
+   WARN_ON(port == 

[Intel-gfx] [BXT MIPI PATCH v3 04/14] drm/i915/bxt: DSI prepare changes for BXT

[Uma Shankar]

From: Shashank Sharma 

This patch modifies dsi_prepare() function to support the same
modeset prepare sequence for BXT also. Main changes are:
1. BXT port control register is different than VLV.
2. BXT modeset sequence needs vdisplay and hdisplay programmed
   for transcoder.
3. BXT can select PIPE for MIPI transcoders.
4. BXT needs to program register MIPI_INIT_COUNT for both the ports,
   even if only one is being used.

v2: Fixed Jani's review comments. Rectified the DSI Macros to get
proper register offsets using _MIPI_PORT instead of _TRANSCODER

v3: Rebased on latest drm-nightly branch. Fixed Jani's review comments.

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h  |   21 
 drivers/gpu/drm/i915/intel_dsi.c |   69 --
 2 files changed, 80 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 06bb2e1..997a999 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7362,6 +7362,22 @@ enum skl_disp_power_wells {
 
 #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
 
+/* BXT MIPI mode configure */
+#define  _BXT_MIPIA_TRANS_HACTIVE  0x6B0F8
+#define  _BXT_MIPIC_TRANS_HACTIVE  0x6B8F8
+#define  BXT_MIPI_TRANS_HACTIVE(tc)_MIPI_PORT(tc, \
+   _BXT_MIPIA_TRANS_HACTIVE, _BXT_MIPIC_TRANS_HACTIVE)
+
+#define  _BXT_MIPIA_TRANS_VACTIVE  0x6B0FC
+#define  _BXT_MIPIC_TRANS_VACTIVE  0x6B8FC
+#define  BXT_MIPI_TRANS_VACTIVE(tc)_MIPI_PORT(tc, \
+   _BXT_MIPIA_TRANS_VACTIVE, _BXT_MIPIC_TRANS_VACTIVE)
+
+#define  _BXT_MIPIA_TRANS_VTOTAL   0x6B100
+#define  _BXT_MIPIC_TRANS_VTOTAL   0x6B900
+#define  BXT_MIPI_TRANS_VTOTAL(tc) _MIPI_PORT(tc, \
+   _BXT_MIPIA_TRANS_VTOTAL, _BXT_MIPIC_TRANS_VTOTAL)
+
 #define BXT_DSI_PLL_CTL0x161000
 #define  BXT_DSI_PLL_PVD_RATIO_SHIFT   16
 #define  BXT_DSI_PLL_PVD_RATIO_MASK(3 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
@@ -7797,6 +7813,11 @@ enum skl_disp_power_wells {
 #define  READ_REQUEST_PRIORITY_HIGH(3 << 3)
 #define  RGB_FLIP_TO_BGR   (1 << 2)
 
+#define  BXT_PIPE_SELECT_MASK  (7 << 7)
+#define  BXT_PIPE_SELECT_C (2 << 7)
+#define  BXT_PIPE_SELECT_B (1 << 7)
+#define  BXT_PIPE_SELECT_A (0 << 7)
+
 #define _MIPIA_DATA_ADDRESS(dev_priv->mipi_mmio_base + 0xb108)
 #define _MIPIC_DATA_ADDRESS(dev_priv->mipi_mmio_base + 0xb908)
 #define MIPI_DATA_ADDRESS(port)_MIPI_PORT(port, 
_MIPIA_DATA_ADDRESS, \
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index bac988a..6d0c992 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -726,6 +726,21 @@ static void set_dsi_timings(struct drm_encoder *encoder,
hbp = txbyteclkhs(hbp, bpp, lane_count, intel_dsi->burst_mode_ratio);
 
for_each_dsi_port(port, intel_dsi->ports) {
+   if (IS_BROXTON(dev)) {
+   /*
+* Program hdisplay and vdisplay on MIPI transcoder.
+* This is different from calculated hactive and
+* vactive, as they are calculated per channel basis,
+* whereas these values should be based on resolution.
+*/
+   I915_WRITE(BXT_MIPI_TRANS_HACTIVE(port),
+   mode->hdisplay);
+   I915_WRITE(BXT_MIPI_TRANS_VACTIVE(port),
+   mode->vdisplay);
+   I915_WRITE(BXT_MIPI_TRANS_VTOTAL(port),
+   mode->vtotal);
+   }
+
I915_WRITE(MIPI_HACTIVE_AREA_COUNT(port), hactive);
I915_WRITE(MIPI_HFP_COUNT(port), hfp);
 
@@ -766,16 +781,39 @@ static void intel_dsi_prepare(struct intel_encoder 
*intel_encoder)
}
 
for_each_dsi_port(port, intel_dsi->ports) {
-   /* escape clock divider, 20MHz, shared for A and C.
-* device ready must be off when doing this! txclkesc? */
-   tmp = I915_READ(MIPI_CTRL(PORT_A));
-   tmp &= ~ESCAPE_CLOCK_DIVIDER_MASK;
-   I915_WRITE(MIPI_CTRL(PORT_A), tmp | ESCAPE_CLOCK_DIVIDER_1);
-
-   /* read request priority is per pipe */
-   tmp = I915_READ(MIPI_CTRL(port));
-   tmp &= ~READ_REQUEST_PRIORITY_MASK;
-   I915_WRITE(MIPI_CTRL(port), tmp | READ_REQUEST_PRIORITY_HIGH);
+   if 

[Intel-gfx] [BXT MIPI PATCH v3 08/14] drm/i915/bxt: DSI disable and post-disable

[Uma Shankar]

From: Shashank Sharma 

This patch contains changes to support DSI disble sequence in BXT.
The changes are:
1. BXT specific changes in clear_device_ready function.
2. BXT specific changes in DSI disable and post-disable functions.
3. Add a new function to reset BXT Dphy clock and dividers
   (bxt_dsi_reset_clocks).
4. Moved some part of the vlv clock reset code, in a new function
   (vlv_dsi_reset_clocks) maintaining the exact same sequence.
5. Wrapper function to call corresponding reset clock function.

v2: Fixed Jani's review comments.

v3: Removed the GET_DSI_PORT_CTRL Macro for consistency with earlier
implementations as per Jani's suggestion.

Signed-off-by: Uma Shankar 
Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_dsi.c |   36 +--
 drivers/gpu/drm/i915/intel_dsi.h |2 ++
 drivers/gpu/drm/i915/intel_dsi_pll.c |   39 ++
 3 files changed, 61 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 5a42f87..110a895 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -421,12 +421,15 @@ static void intel_dsi_port_disable(struct intel_encoder 
*encoder)
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
enum port port;
u32 temp;
+   u32 port_ctrl;
 
for_each_dsi_port(port, intel_dsi->ports) {
/* de-assert ip_tg_enable signal */
-   temp = I915_READ(MIPI_PORT_CTRL(port));
-   I915_WRITE(MIPI_PORT_CTRL(port), temp & ~DPI_ENABLE);
-   POSTING_READ(MIPI_PORT_CTRL(port));
+   port_ctrl = IS_BROXTON(dev) ? BXT_MIPI_PORT_CTRL(port) :
+   MIPI_PORT_CTRL(port);
+   temp = I915_READ(port_ctrl);
+   I915_WRITE(port_ctrl, temp & ~DPI_ENABLE);
+   POSTING_READ(port_ctrl);
}
 }
 
@@ -550,12 +553,7 @@ static void intel_dsi_disable(struct intel_encoder 
*encoder)
/* Panel commands can be sent when clock is in LP11 */
I915_WRITE(MIPI_DEVICE_READY(port), 0x0);
 
-   temp = I915_READ(MIPI_CTRL(port));
-   temp &= ~ESCAPE_CLOCK_DIVIDER_MASK;
-   I915_WRITE(MIPI_CTRL(port), temp |
-  intel_dsi->escape_clk_div <<
-  ESCAPE_CLOCK_DIVIDER_SHIFT);
-
+   intel_dsi_reset_clocks(encoder, port);
I915_WRITE(MIPI_EOT_DISABLE(port), CLOCKSTOP);
 
temp = I915_READ(MIPI_DSI_FUNC_PRG(port));
@@ -574,10 +572,12 @@ static void intel_dsi_disable(struct intel_encoder 
*encoder)
 
 static void intel_dsi_clear_device_ready(struct intel_encoder *encoder)
 {
+   struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
enum port port;
u32 val;
+   u32 port_ctrl = 0;
 
DRM_DEBUG_KMS("\n");
for_each_dsi_port(port, intel_dsi->ports) {
@@ -594,18 +594,22 @@ static void intel_dsi_clear_device_ready(struct 
intel_encoder *encoder)
ULPS_STATE_ENTER);
usleep_range(2000, 2500);
 
+   if (IS_BROXTON(dev))
+   port_ctrl = BXT_MIPI_PORT_CTRL(port);
+   else if (IS_VALLEYVIEW(dev))
+   /* Common bit for both MIPI Port A & MIPI Port C */
+   port_ctrl = MIPI_PORT_CTRL(PORT_A);
+
/* Wait till Clock lanes are in LP-00 state for MIPI Port A
 * only. MIPI Port C has no similar bit for checking
 */
-   if (wait_for(((I915_READ(MIPI_PORT_CTRL(PORT_A)) & AFE_LATCHOUT)
-   == 0x0), 30))
+   if (wait_for(((I915_READ(port_ctrl) & AFE_LATCHOUT)
+   == 0x0), 30))
DRM_ERROR("DSI LP not going Low\n");
 
-   /* Disable MIPI PHY transparent latch
-* Common bit for both MIPI Port A & MIPI Port C
-*/
-   val = I915_READ(MIPI_PORT_CTRL(PORT_A));
-   I915_WRITE(MIPI_PORT_CTRL(PORT_A), val & ~LP_OUTPUT_HOLD);
+   /* Disable MIPI PHY transparent latch */
+   val = I915_READ(port_ctrl);
+   I915_WRITE(port_ctrl, val & ~LP_OUTPUT_HOLD);
usleep_range(1000, 1500);
 
I915_WRITE(MIPI_DEVICE_READY(port), 0x00);
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 759983e..078ea1b 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -124,6 +124,8 @@ static inline struct 

[Intel-gfx] [BXT MIPI PATCH v3 11/14] drm/i915/bxt: Modify BXT BLC according to VBT changes

[Uma Shankar]

From: Sunil Kamath 

Latest VBT mentions which set of registers will be used for BLC,
as controller number field. Making use of this field in BXT
BLC implementation. Also, the registers are used in case control
pin indicates display DDI. Adding a check for this.
According to Bspec, BLC_PWM_*_2 uses the display utility pin for output.
To use backlight 2, enable the utility pin with mode = PWM
   v2: Jani's review comments
   addressed
   - Add a prefix _ to BXT BLC registers definitions.
   - Add "bxt only" comment for u8 controller
   - Remove control_pin check for DDI controller
   - Check for valid controller values
   - Set pipe bits in UTIL_PIN_CTL
   - Enable/Disable UTIL_PIN_CTL in enable/disable_backlight()
   - If BLC 2 is used, read active_low_pwm from UTIL_PIN polarity
   Satheesh's review comment addressed
   - If UTIL PIN is already enabled, BIOS would have programmed it. No
   need to disable and enable again.
   v3: Jani's review comments
   - add UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK
   - Disable UTIL_PIN if controller 1 is used
   - Mask out UTIL_PIN_PIPE_MASK and UTIL_PIN_MODE_MASK before enabling
   UTIL_PIN
   - check valid controller value in intel_bios.c
   - add backlight.util_pin_active_low
   - disable util pin before enabling
   v4: Change for BXT-PO branch:
   Stubbed unwanted definition which was existing before
   because of DC6 patch.
   UTIL_PIN_MODE_PWM (0x1b << 24)

v2: Fixed Jani's review comment.

v3: Split the backight PWM frequency programming into separate patch,
in cases BIOS doesn't initializes it.

Signed-off-by: Vandana Kannan 
Signed-off-by: Sunil Kamath 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h|   28 
 drivers/gpu/drm/i915/intel_drv.h   |2 +
 drivers/gpu/drm/i915/intel_panel.c |   84 
 3 files changed, 89 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e43b053..8407b5c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3512,17 +3512,29 @@ enum skl_disp_power_wells {
 #define UTIL_PIN_CTL   0x48400
 #define   UTIL_PIN_ENABLE  (1 << 31)
 
+#define   UTIL_PIN_PIPE(x) ((x) << 29)
+#define   UTIL_PIN_PIPE_MASK   (3 << 29)
+#define   UTIL_PIN_MODE_PWM(1 << 24)
+#define   UTIL_PIN_MODE_MASK   (0xf << 24)
+#define   UTIL_PIN_POLARITY(1 << 22)
+
 /* BXT backlight register definition. */
-#define BXT_BLC_PWM_CTL1   0xC8250
+#define _BXT_BLC_PWM_CTL1  0xC8250
 #define   BXT_BLC_PWM_ENABLE   (1 << 31)
 #define   BXT_BLC_PWM_POLARITY (1 << 29)
-#define BXT_BLC_PWM_FREQ1  0xC8254
-#define BXT_BLC_PWM_DUTY1  0xC8258
-
-#define BXT_BLC_PWM_CTL2   0xC8350
-#define BXT_BLC_PWM_FREQ2  0xC8354
-#define BXT_BLC_PWM_DUTY2  0xC8358
-
+#define _BXT_BLC_PWM_FREQ1 0xC8254
+#define _BXT_BLC_PWM_DUTY1 0xC8258
+
+#define _BXT_BLC_PWM_CTL2  0xC8350
+#define _BXT_BLC_PWM_FREQ2 0xC8354
+#define _BXT_BLC_PWM_DUTY2 0xC8358
+
+#define BXT_BLC_PWM_CTL(controller)_PIPE(controller, \
+   _BXT_BLC_PWM_CTL1, _BXT_BLC_PWM_CTL2)
+#define BXT_BLC_PWM_FREQ(controller)   _PIPE(controller, \
+   _BXT_BLC_PWM_FREQ1, _BXT_BLC_PWM_FREQ2)
+#define BXT_BLC_PWM_DUTY(controller)   _PIPE(controller, \
+   _BXT_BLC_PWM_DUTY1, _BXT_BLC_PWM_DUTY2)
 
 #define PCH_GTC_CTL0xe7000
 #define   PCH_GTC_ENABLE   (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1059283..d8ca075 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -182,7 +182,9 @@ struct intel_panel {
bool enabled;
bool combination_mode;  /* gen 2/4 only */
bool active_low_pwm;
+   bool util_pin_active_low;   /* bxt+ */
struct backlight_device *device;
+   u8 controller;  /* bxt+ only */
} backlight;
 
void (*backlight_power)(struct intel_connector *, bool enable);
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 55aad23..9fcf86c 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -539,9 +539,10 @@ static u32 vlv_get_backlight(struct intel_connector 
*connector)
 static u32 bxt_get_backlight(struct intel_connector *connector)
 {
struct drm_device *dev = connector->base.dev;
+   struct intel_panel *panel = 

[Intel-gfx] [BXT MIPI PATCH v3 12/14] drm/i915/bxt: Program Backlight PWM frequency

[Uma Shankar]

In some cases, BIOS doesn't initializes DSI panel.DSI and
backlight registers are thereby not initialized. Programming
the same in driver backlight setup.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h|3 +++
 drivers/gpu/drm/i915/intel_panel.c |   11 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8407b5c..10f73b1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7166,6 +7166,9 @@ enum skl_disp_power_wells {
 #define  TRANS_MSA_12_BPC  (3<<5)
 #define  TRANS_MSA_16_BPC  (4<<5)
 
+/* Max CDCLK freq for BXT in HZ */
+#define BXT_CDCLK_MAX   62400
+
 /* LCPLL Control */
 #define LCPLL_CTL  0x130040
 #define  LCPLL_PLL_DISABLE (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 9fcf86c..8225cea 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1427,6 +1427,17 @@ bxt_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
panel->backlight.max = I915_READ(
BXT_BLC_PWM_FREQ(panel->backlight.controller));
 
+   if (!panel->backlight.max) {
+   DRM_DEBUG_KMS("PWM freq not programmed by BIOS\n");
+   DRM_DEBUG_KMS("Programming PWM freq\n");
+
+   /* Max Backlight = Max CD Clock / pwm freq) */
+   panel->backlight.max = (BXT_CDCLK_MAX /
+   dev_priv->vbt.backlight.pwm_freq_hz);
+   I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
+   panel->backlight.max);
+   }
+
val = bxt_get_backlight(connector);
panel->backlight.level = intel_panel_compute_brightness(connector, val);
 
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [BXT MIPI PATCH v3 10/14] drm/i915/bxt: get DSI pixelclock

[Uma Shankar]

From: Shashank Sharma 

BXT's DSI PLL is different from that of VLV. So this patch
adds a new function to get the current DSI pixel clock based
on the PLL divider ratio and lane count.

This function is required for intel_dsi_get_config() function.

v2: Fixed Jani's review comments.

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dsi.c |8 ++--
 drivers/gpu/drm/i915/intel_dsi.h |1 +
 drivers/gpu/drm/i915/intel_dsi_pll.c |   35 ++
 3 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 001569b..6a0071f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -687,7 +687,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder 
*encoder,
 static void intel_dsi_get_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config)
 {
-   u32 pclk;
+   u32 pclk = 0;
DRM_DEBUG_KMS("\n");
 
/*
@@ -696,7 +696,11 @@ static void intel_dsi_get_config(struct intel_encoder 
*encoder,
 */
pipe_config->dpll_hw_state.dpll_md = 0;
 
-   pclk = vlv_get_dsi_pclk(encoder, pipe_config->pipe_bpp);
+   if (IS_BROXTON(encoder->base.dev))
+   pclk = bxt_get_dsi_pclk(encoder, pipe_config->pipe_bpp);
+   else if (IS_VALLEYVIEW(encoder->base.dev))
+   pclk = vlv_get_dsi_pclk(encoder, pipe_config->pipe_bpp);
+
if (!pclk)
return;
 
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 078ea1b..24fc550 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -124,6 +124,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct 
drm_encoder *encoder)
 extern void intel_enable_dsi_pll(struct intel_encoder *encoder);
 extern void intel_disable_dsi_pll(struct intel_encoder *encoder);
 extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
+extern u32 bxt_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
 extern void intel_dsi_reset_clocks(struct intel_encoder *encoder,
enum port port);
 
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 918bc5f..9860bb5 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -389,6 +389,41 @@ u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int 
pipe_bpp)
return pclk;
 }
 
+u32 bxt_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp)
+{
+   u32 pclk;
+   u32 dsi_clk;
+   u32 dsi_ratio;
+   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+
+   /* Divide by zero */
+   if (!pipe_bpp) {
+   DRM_ERROR("Invalid BPP(0)\n");
+   return 0;
+   }
+
+   dsi_ratio = I915_READ(BXT_DSI_PLL_CTL) &
+   BXT_DSI_PLL_RATIO_MASK;
+
+   /* Invalid DSI ratio ? */
+   if (dsi_ratio < BXT_DSI_PLL_RATIO_MIN ||
+   dsi_ratio > BXT_DSI_PLL_RATIO_MAX) {
+   DRM_ERROR("Invalid DSI pll ratio(%u) programmed\n", dsi_ratio);
+   return 0;
+   }
+
+   dsi_clk = (dsi_ratio * BXT_REF_CLOCK_KHZ) / 2;
+
+   /* pixel_format and pipe_bpp should agree */
+   assert_bpp_mismatch(intel_dsi->pixel_format, pipe_bpp);
+
+   pclk = DIV_ROUND_CLOSEST(dsi_clk * intel_dsi->lane_count, pipe_bpp);
+
+   DRM_DEBUG_DRIVER("Calculated pclk=%u\n", pclk);
+   return pclk;
+}
+
 void vlv_dsi_reset_clocks(struct intel_encoder *encoder, enum port port)
 {
u32 temp;
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [BXT MIPI PATCH v3 13/14] drm/i915/bxt: Remove DSP CLK_GATE programming for BXT

[Uma Shankar]

DSP CLK_GATE registers are specific to BYT and CHT.
Avoid programming the same for BXT platform.

v2: Rebased on latest drm nightly branch.

v3: Fixed Jani's review comments

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dsi.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 6a0071f..08bade2 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -631,9 +631,11 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder)
 
intel_dsi_clear_device_ready(encoder);
 
-   val = I915_READ(DSPCLK_GATE_D);
-   val &= ~DPOUNIT_CLOCK_GATE_DISABLE;
-   I915_WRITE(DSPCLK_GATE_D, val);
+   if (!IS_BROXTON(dev_priv->dev)) {
+   val = I915_READ(DSPCLK_GATE_D);
+   val &= ~DPOUNIT_CLOCK_GATE_DISABLE;
+   I915_WRITE(DSPCLK_GATE_D, val);
+   }
 
drm_panel_unprepare(intel_dsi->panel);
 
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [BXT MIPI PATCH v3 02/14] drm/i915/bxt: Enable BXT DSI PLL

[Uma Shankar]

From: Shashank Sharma 

This patch adds new functions for BXT clock and PLL programming.
They are:
1. configure_dsi_pll for BXT.
   This function does the basic math and generates the divider ratio
   based on requested pixclock, and program clock registers.
2. enable_dsi_pll function.
   This function programs the calculated clock values on the PLL.
3. intel_enable_dsi_pll
   Wrapper function to use same code for multiple platforms. It checks the
   platform and calls appropriate core pll enable function.

v2: Fixed Jani's review comments. Macros are adjusted as per convention.

v3: Removed a redundant change wrt code comment.

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h  |   22 
 drivers/gpu/drm/i915/intel_dsi.c |2 +-
 drivers/gpu/drm/i915/intel_dsi.h |2 +-
 drivers/gpu/drm/i915/intel_dsi_pll.c |   95 +-
 4 files changed, 118 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 621151b..06bb2e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7362,6 +7362,28 @@ enum skl_disp_power_wells {
 
 #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
 
+#define BXT_DSI_PLL_CTL0x161000
+#define  BXT_DSI_PLL_PVD_RATIO_SHIFT   16
+#define  BXT_DSI_PLL_PVD_RATIO_MASK(3 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
+#define  BXT_DSI_PLL_PVD_RATIO_1   (1 << BXT_DSI_PLL_PVD_RATIO_SHIFT)
+#define  BXT_DSIC_16X_BY2  (1 << 10)
+#define  BXT_DSIC_16X_BY3  (2 << 10)
+#define  BXT_DSIC_16X_BY4  (3 << 10)
+#define  BXT_DSIA_16X_BY2  (1 << 8)
+#define  BXT_DSIA_16X_BY3  (2 << 8)
+#define  BXT_DSIA_16X_BY4  (3 << 8)
+#define  BXT_DSI_FREQ_SEL_SHIFT8
+#define  BXT_DSI_FREQ_SEL_MASK (0xF << BXT_DSI_FREQ_SEL_SHIFT)
+
+#define BXT_DSI_PLL_RATIO_MAX  0x7D
+#define BXT_DSI_PLL_RATIO_MIN  0x22
+#define BXT_DSI_PLL_RATIO_MASK 0xFF
+#define BXT_REF_CLOCK_KHZ  19500
+
+#define BXT_DSI_PLL_ENABLE 0x46080
+#define  BXT_DSI_PLL_DO_ENABLE (1 << 31)
+#define  BXT_DSI_PLL_LOCKED(1 << 30)
+
 #define _MIPIA_PORT_CTRL   (VLV_DISPLAY_BASE + 0x61190)
 #define _MIPIC_PORT_CTRL   (VLV_DISPLAY_BASE + 0x61700)
 #define MIPI_PORT_CTRL(port)   _MIPI_PORT(port, _MIPIA_PORT_CTRL, 
_MIPIC_PORT_CTRL)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b59b828..fb259fb 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -903,8 +903,8 @@ static void intel_dsi_pre_pll_enable(struct intel_encoder 
*encoder)
DRM_DEBUG_KMS("\n");
 
intel_dsi_prepare(encoder);
+   intel_enable_dsi_pll(encoder);
 
-   vlv_enable_dsi_pll(encoder);
 }
 
 static enum drm_connector_status
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 2784ac4..20cfcf07 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -121,7 +121,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct 
drm_encoder *encoder)
return container_of(encoder, struct intel_dsi, base.base);
 }
 
-extern void vlv_enable_dsi_pll(struct intel_encoder *encoder);
+extern void intel_enable_dsi_pll(struct intel_encoder *encoder);
 extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
 extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
 
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index d20cf37..3830a4f 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -237,7 +237,7 @@ static void vlv_configure_dsi_pll(struct intel_encoder 
*encoder)
vlv_cck_write(dev_priv, CCK_REG_DSI_PLL_CONTROL, dsi_mnp.dsi_pll_ctrl);
 }
 
-void vlv_enable_dsi_pll(struct intel_encoder *encoder)
+static void vlv_enable_dsi_pll(struct intel_encoder *encoder)
 {
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
u32 tmp;
@@ -368,3 +368,96 @@ u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int 
pipe_bpp)
 
return pclk;
 }
+
+static bool bxt_configure_dsi_pll(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   u8 dsi_ratio;
+   u32 dsi_clk;
+   u32 val;
+
+   dsi_clk = dsi_clk_from_pclk(intel_dsi->pclk, intel_dsi->pixel_format,
+   intel_dsi->lane_count);
+
+   /*
+* From clock diagram, to get PLL ratio divider, divide double of DSI
+* link rate (i.e., 2*8x=16x frequency value) by ref clock. Make sure to
+ 

[Intel-gfx] [BXT MIPI PATCH v3 14/14] drm/i915: Added BXT DSI backlight support

[Uma Shankar]

DSI backlight support for bxt is added.

TODO: There is no support for backlight control in drm panel
  framework. This will be added as part of VBT version patches
  fixing the backlight sequence.

v2: Fixed Jani's review comments from previous patch. Added the
BXT DSI backlight code in this patch. Backlight setup and
enable/disable code for backlight is added in intel_dsi.c.

v3: Rebased on latest drm-nightly. Fixed Jani's review comments.

Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dsi.c |   20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 08bade2..aee1539 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -438,6 +438,7 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   struct intel_connector *intel_connector = intel_dsi->attached_connector;
enum port port;
 
DRM_DEBUG_KMS("\n");
@@ -458,6 +459,11 @@ static void intel_dsi_enable(struct intel_encoder *encoder)
 
intel_dsi_port_enable(encoder);
}
+
+   if (IS_BROXTON(dev)) {
+   msleep(intel_dsi->backlight_on_delay);
+   intel_panel_enable_backlight(intel_connector);
+   }
 }
 
 static void intel_dsi_pre_enable(struct intel_encoder *encoder)
@@ -623,10 +629,16 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder)
 {
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
+   struct intel_connector *intel_connector = intel_dsi->attached_connector;
u32 val;
 
DRM_DEBUG_KMS("\n");
 
+   if (IS_BROXTON(dev_priv->dev)) {
+   intel_panel_disable_backlight(intel_connector);
+   msleep(intel_dsi->backlight_off_delay);
+   }
+
intel_dsi_disable(encoder);
 
intel_dsi_clear_device_ready(encoder);
@@ -1226,8 +1238,14 @@ void intel_dsi_init(struct drm_device *dev)
 
intel_panel_init(_connector->panel, fixed_mode, NULL);
 
-   return;
+   /*
+* Pipe parameter is not used for BXT.
+* Passing INVALID_PIPE to adher to API requirement.
+*/
+   if (IS_BROXTON(dev))
+   intel_panel_setup_backlight(connector, INVALID_PIPE);
 
+   return;
 err:
drm_encoder_cleanup(_encoder->base);
kfree(intel_dsi);
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [BXT MIPI PATCH v3 09/14] drm/i915/bxt: get_hw_state for BXT

[Uma Shankar]

From: Shashank Sharma 

Pick appropriate port control register (BXT or VLV), based on device.
Get the current hw state wrt Mipi port.

v2: Rebased on latest drm nightly branch.

v3: Removed the GET_DSI_PORT_CTRL Macro for consistency with earlier
implementations as per Jani's suggestion.

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dsi.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 110a895..001569b 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -648,7 +648,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder 
*encoder,
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
struct drm_device *dev = encoder->base.dev;
enum intel_display_power_domain power_domain;
-   u32 dpi_enabled, func;
+   u32 dpi_enabled, func, ctrl_reg;
enum port port;
 
DRM_DEBUG_KMS("\n");
@@ -660,8 +660,9 @@ static bool intel_dsi_get_hw_state(struct intel_encoder 
*encoder,
/* XXX: this only works for one DSI output */
for_each_dsi_port(port, intel_dsi->ports) {
func = I915_READ(MIPI_DSI_FUNC_PRG(port));
-   dpi_enabled = I915_READ(MIPI_PORT_CTRL(port)) &
-   DPI_ENABLE;
+   ctrl_reg = IS_BROXTON(dev) ? BXT_MIPI_PORT_CTRL(port) :
+   MIPI_PORT_CTRL(port);
+   dpi_enabled = I915_READ(ctrl_reg) & DPI_ENABLE;
 
/* Due to some hardware limitations on BYT, MIPI Port C DPI
 * Enable bit does not get set. To check whether DSI Port C
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [BXT MIPI PATCH v3 07/14] drm/i915/bxt: Program Tx Rx and Dphy clocks

[Uma Shankar]

From: Shashank Sharma 

BXT DSI clocks are different than previous platforms. So adding a
new function to program following clocks and dividers:
1. Program variable divider to generate input to Tx clock divider
   (Output value must be < 39.5Mhz)
2. Select divide by 2 option to get < 20Mhz for Tx clock
3. Program 8by3 divider to generate Rx clock

v2: Fixed Jani's review comments. Adjusted the Macro definition as
per convention. Simplified the logic for bit definitions for
MIPI PORT A and PORT C in same registers.

v3: Refactored the macros for TX, RX Escape and DPHY clocks as per
Jani's suggestion.

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h  |   62 ++
 drivers/gpu/drm/i915/intel_dsi_pll.c |   39 +
 2 files changed, 101 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 57c5dbf..e43b053 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7362,6 +7362,68 @@ enum skl_disp_power_wells {
 
 #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
 
+/* BXT MIPI clock controls */
+#define BXT_MAX_VAR_OUTPUT_KHZ 39500
+
+#define BXT_MIPI_CLOCK_CTL 0x46090
+#define  BXT_MIPI1_DIV_SHIFT   26
+#define  BXT_MIPI2_DIV_SHIFT   10
+#define  BXT_MIPI_DIV_SHIFT(port)  \
+   _MIPI_PORT(port, BXT_MIPI1_DIV_SHIFT, \
+   BXT_MIPI2_DIV_SHIFT)
+/* Var clock divider to generate TX source. Result must be < 39.5 M */
+#define  BXT_MIPI1_ESCLK_VAR_DIV_MASK  (0x3F << 26)
+#define  BXT_MIPI2_ESCLK_VAR_DIV_MASK  (0x3F << 10)
+#define  BXT_MIPI_ESCLK_VAR_DIV_MASK(port) \
+   _MIPI_PORT(port, BXT_MIPI1_ESCLK_VAR_DIV_MASK, \
+   BXT_MIPI2_ESCLK_VAR_DIV_MASK)
+
+#define  BXT_MIPI_ESCLK_VAR_DIV(port, val) \
+   (val << BXT_MIPI_DIV_SHIFT(port))
+/* TX control divider to select actual TX clock output from (8x/var) */
+#define  BXT_MIPI1_TX_ESCLK_SHIFT  21
+#define  BXT_MIPI2_TX_ESCLK_SHIFT  5
+#define  BXT_MIPI_TX_ESCLK_SHIFT(port) \
+   _MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_SHIFT, \
+   BXT_MIPI2_TX_ESCLK_SHIFT)
+#define  BXT_MIPI1_TX_ESCLK_FIXDIV_MASK(3 << 21)
+#define  BXT_MIPI2_TX_ESCLK_FIXDIV_MASK(3 << 5)
+#define  BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port)   \
+   _MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_FIXDIV_MASK, \
+   BXT_MIPI2_TX_ESCLK_FIXDIV_MASK)
+#define  BXT_MIPI_TX_ESCLK_8XDIV_BY2(port) \
+   (0x0 << BXT_MIPI_TX_ESCLK_SHIFT(port))
+#define  BXT_MIPI_TX_ESCLK_8XDIV_BY4(port) \
+   (0x1 << BXT_MIPI_TX_ESCLK_SHIFT(port))
+#define  BXT_MIPI_TX_ESCLK_8XDIV_BY8(port) \
+   (0x2 << BXT_MIPI_TX_ESCLK_SHIFT(port))
+/* RX control divider to select actual RX clock output from 8x*/
+#define  BXT_MIPI1_RX_ESCLK_SHIFT  19
+#define  BXT_MIPI2_RX_ESCLK_SHIFT  3
+#define  BXT_MIPI_RX_ESCLK_SHIFT(port) \
+   _MIPI_PORT(port, BXT_MIPI1_RX_ESCLK_SHIFT, \
+   BXT_MIPI2_RX_ESCLK_SHIFT)
+#define  BXT_MIPI1_RX_ESCLK_FIXDIV_MASK(3 << 19)
+#define  BXT_MIPI2_RX_ESCLK_FIXDIV_MASK(3 << 3)
+#define  BXT_MIPI_RX_ESCLK_FIXDIV_MASK(port)   \
+   (3 << BXT_MIPI_RX_ESCLK_SHIFT(port))
+#define  BXT_MIPI_RX_ESCLK_8X_BY2(port)\
+   (1 << BXT_MIPI_RX_ESCLK_SHIFT(port))
+#define  BXT_MIPI_RX_ESCLK_8X_BY3(port)\
+   (2 << BXT_MIPI_RX_ESCLK_SHIFT(port))
+#define  BXT_MIPI_RX_ESCLK_8X_BY4(port)\
+   (3 << BXT_MIPI_RX_ESCLK_SHIFT(port))
+/* BXT: Always prog DPHY dividers to 00 */
+#define  BXT_MIPI1_DPHY_DIV_SHIFT  16
+#define  BXT_MIPI2_DPHY_DIV_SHIFT  0
+#define  BXT_MIPI_DPHY_DIV_SHIFT(port) \
+   _MIPI_PORT(port, BXT_MIPI1_DPHY_DIV_SHIFT, \
+   BXT_MIPI2_DPHY_DIV_SHIFT)
+#define  BXT_MIPI_1_DPHY_DIVIDER_MASK  (3 << 16)
+#define  BXT_MIPI_2_DPHY_DIVIDER_MASK  (3 << 0)
+#define  BXT_MIPI_DPHY_DIVIDER_MASK(port)  \
+   (3 << BXT_MIPI_DPHY_DIV_SHIFT(port))
+
 /* BXT MIPI mode configure */
 #define  _BXT_MIPIA_TRANS_HACTIVE  0x6B0F8
 #define  _BXT_MIPIC_TRANS_HACTIVE  0x6B8F8
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 21a2e37..63f9aed 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ 

[Intel-gfx] [BXT MIPI PATCH v3 06/14] drm/i915/bxt: DSI enable for BXT

[Uma Shankar]

From: Shashank Sharma 

This patch contains following changes:
1. MIPI device ready changes to support dsi_pre_enable. Changes
   are specific to BXT device ready sequence. Added check for
   ULPS mode(No effects on VLV).
2. Changes in dsi_enable to pick BXT port control register.
3. Changes in dsi_pre_enable to restrict DPIO programming for VLV

v2: Fixed Jani's review comments. Removed the changes in VLV/CHV
code. Fixed the macros to get proper port offsets.

v3: Rebased on latest drm-nightly branch. Fixed Jani's review comments.

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h  |7 ++
 drivers/gpu/drm/i915/intel_dsi.c |  165 ++
 2 files changed, 119 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 997a999..57c5dbf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7403,6 +7403,13 @@ enum skl_disp_power_wells {
 #define _MIPIA_PORT_CTRL   (VLV_DISPLAY_BASE + 0x61190)
 #define _MIPIC_PORT_CTRL   (VLV_DISPLAY_BASE + 0x61700)
 #define MIPI_PORT_CTRL(port)   _MIPI_PORT(port, _MIPIA_PORT_CTRL, 
_MIPIC_PORT_CTRL)
+
+ /* BXT port control */
+#define _BXT_MIPIA_PORT_CTRL   0x6B0C0
+#define _BXT_MIPIC_PORT_CTRL   0x6B8C0
+#define BXT_MIPI_PORT_CTRL(tc) _MIPI_PORT(tc, _BXT_MIPIA_PORT_CTRL, \
+   _BXT_MIPIC_PORT_CTRL)
+
 #define  DPI_ENABLE(1 << 31) /* A + C */
 #define  MIPIA_MIPI4DPHY_DELAY_COUNT_SHIFT 27
 #define  MIPIA_MIPI4DPHY_DELAY_COUNT_MASK  (0xf << 27)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 6d0c992..5a42f87 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -286,58 +286,46 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
return true;
 }
 
-static void intel_dsi_port_enable(struct intel_encoder *encoder)
+static void bxt_dsi_device_ready(struct intel_encoder *encoder)
 {
-   struct drm_device *dev = encoder->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
enum port port;
-   u32 temp;
+   u32 val;
 
-   if (intel_dsi->dual_link == DSI_DUAL_LINK_FRONT_BACK) {
-   temp = I915_READ(VLV_CHICKEN_3);
-   temp &= ~PIXEL_OVERLAP_CNT_MASK |
-   intel_dsi->pixel_overlap <<
-   PIXEL_OVERLAP_CNT_SHIFT;
-   I915_WRITE(VLV_CHICKEN_3, temp);
-   }
+   DRM_DEBUG_KMS("\n");
 
+   /* Exit Low power state in 4 steps*/
for_each_dsi_port(port, intel_dsi->ports) {
-   temp = I915_READ(MIPI_PORT_CTRL(port));
-   temp &= ~LANE_CONFIGURATION_MASK;
-   temp &= ~DUAL_LINK_MODE_MASK;
 
-   if (intel_dsi->ports == ((1 << PORT_A) | (1 << PORT_C))) {
-   temp |= (intel_dsi->dual_link - 1)
-   << DUAL_LINK_MODE_SHIFT;
-   temp |= intel_crtc->pipe ?
-   LANE_CONFIGURATION_DUAL_LINK_B :
-   LANE_CONFIGURATION_DUAL_LINK_A;
-   }
-   /* assert ip_tg_enable signal */
-   I915_WRITE(MIPI_PORT_CTRL(port), temp | DPI_ENABLE);
-   POSTING_READ(MIPI_PORT_CTRL(port));
-   }
-}
+   /* 1. Enable MIPI PHY transparent latch */
+   val = I915_READ(BXT_MIPI_PORT_CTRL(port));
+   I915_WRITE(BXT_MIPI_PORT_CTRL(port), val | LP_OUTPUT_HOLD);
+   usleep_range(2000, 2500);
 
-static void intel_dsi_port_disable(struct intel_encoder *encoder)
-{
-   struct drm_device *dev = encoder->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
-   enum port port;
-   u32 temp;
+   /* 2. Enter ULPS */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_ENTER | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+   usleep_range(2, 3);
+
+   /* 3. Exit ULPS */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_EXIT | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
+   

[Intel-gfx] [BXT MIPI PATCH v3 01/14] drm/i915/bxt: Initialize MIPI for BXT

[Uma Shankar]

From: Shashank Sharma 

This patch contains following changes:
1. Add BXT MIPI display address base.
2. Call dsi_init from display_setup function.

v2: Rebased on latest nightly branch

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/i915_reg.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |3 +++
 drivers/gpu/drm/i915/intel_dsi.c |2 ++
 3 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2030f60..621151b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1641,6 +1641,7 @@ enum skl_disp_power_wells {
 
 #define VLV_DISPLAY_BASE 0x18
 #define VLV_MIPI_BASE VLV_DISPLAY_BASE
+#define BXT_MIPI_BASE 0x6
 
 #define VLV_GU_CTL0(VLV_DISPLAY_BASE + 0x2030)
 #define VLV_GU_CTL1(VLV_DISPLAY_BASE + 0x2034)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 87476ff..b8e0310 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13906,6 +13906,9 @@ static void intel_setup_outputs(struct drm_device *dev)
 * DDI_BUF_CTL_A or SFUSE_STRAP registers, find another way to
 * detect the ports.
 */
+   /* Initialize MIPI for BXT */
+   intel_dsi_init(dev);
+
intel_ddi_init(dev, PORT_A);
intel_ddi_init(dev, PORT_B);
intel_ddi_init(dev, PORT_C);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index b5a5558..b59b828 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -998,6 +998,8 @@ void intel_dsi_init(struct drm_device *dev)
 
if (IS_VALLEYVIEW(dev)) {
dev_priv->mipi_mmio_base = VLV_MIPI_BASE;
+   } else if (IS_BROXTON(dev)) {
+   dev_priv->mipi_mmio_base = BXT_MIPI_BASE;
} else {
DRM_ERROR("Unsupported Mipi device to reg base");
return;
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [BXT MIPI PATCH v3 00/14] MIPI DSI Support for BXT

[Uma Shankar]

This patch series adds support for MIPI DSI for BXT platform.
Support for VBT v3 sequence parsing and programming is needed
for panel, backlight enable and control. The same will be added
as part of a different patch series. This is already floated and
is under review.

Below is the link for earlier patch series in mailing list:
v1: http://www.spinics.net/lists/intel-gfx/msg67354.html
v2: http://lists.freedesktop.org/archives/intel-gfx/2015-July/072353.html

v2: Addressed the review comments from Jani. Fixed Macros
definitions as per convention. Adjusted the BXT DSI MACROS to
get proper offsets for PORT C. DDI/DSI handling in generic
code has been simplified. Backlight handling for BXT DSI has
been re-designed.

v3: Rebased on latest drm-nightly branch. Addressed review comments
fom Jani.

Shashank Sharma (10):
  drm/i915/bxt: Initialize MIPI for BXT
  drm/i915/bxt: Enable BXT DSI PLL
  drm/i915/bxt: Disable DSI PLL for BXT
  drm/i915/bxt: DSI prepare changes for BXT
  drm/i915/bxt: DSI encoder support in CRTC modeset
  drm/i915/bxt: DSI enable for BXT
  drm/i915/bxt: Program Tx Rx and Dphy clocks
  drm/i915/bxt: DSI disable and post-disable
  drm/i915/bxt: get_hw_state for BXT
  drm/i915/bxt: get DSI pixelclock

Sunil Kamath (1):
  drm/i915/bxt: Modify BXT BLC according to VBT changes

Uma Shankar (3):
  drm/i915/bxt: Program Backlight PWM frequency
  drm/i915/bxt: Remove DSP CLK_GATE programming for BXT
  drm/i915: Added BXT DSI backlight support

 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/i915_reg.h   |  140 ++-
 drivers/gpu/drm/i915/intel_ddi.c  |   29 ++-
 drivers/gpu/drm/i915/intel_display.c  |   22 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c   |1 +
 drivers/gpu/drm/i915/intel_drv.h  |2 +
 drivers/gpu/drm/i915/intel_dsi.c  |  313 -
 drivers/gpu/drm/i915/intel_dsi.h  |7 +-
 drivers/gpu/drm/i915/intel_dsi_pll.c  |  240 -
 drivers/gpu/drm/i915/intel_opregion.c |3 +-
 drivers/gpu/drm/i915/intel_panel.c|   95 --
 11 files changed, 732 insertions(+), 121 deletions(-)

-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [BXT MIPI PATCH v3 03/14] drm/i915/bxt: Disable DSI PLL for BXT

[Uma Shankar]

From: Shashank Sharma 

This patch adds two new functions:
- disable_dsi_pll.
  BXT DSI disable sequence and registers are
  different from previous platforms.
- intel_disable_dsi_pll
  wrapper function to re-use the same code for
  multiple platforms. It checks platform type and
  calls appropriate core pll disable function.

v2: Fixed Jani's review comments.

v3: Rebased on latest drm-nightly branch.

Signed-off-by: Shashank Sharma 
Signed-off-by: Uma Shankar 
---
 drivers/gpu/drm/i915/intel_dsi.c |2 +-
 drivers/gpu/drm/i915/intel_dsi.h |2 +-
 drivers/gpu/drm/i915/intel_dsi_pll.c |   32 +++-
 3 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index fb259fb..bac988a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -553,7 +553,7 @@ static void intel_dsi_clear_device_ready(struct 
intel_encoder *encoder)
usleep_range(2000, 2500);
}
 
-   vlv_disable_dsi_pll(encoder);
+   intel_disable_dsi_pll(encoder);
 }
 
 static void intel_dsi_post_disable(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 20cfcf07..759983e 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -122,7 +122,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct 
drm_encoder *encoder)
 }
 
 extern void intel_enable_dsi_pll(struct intel_encoder *encoder);
-extern void vlv_disable_dsi_pll(struct intel_encoder *encoder);
+extern void intel_disable_dsi_pll(struct intel_encoder *encoder);
 extern u32 vlv_get_dsi_pclk(struct intel_encoder *encoder, int pipe_bpp);
 
 struct drm_panel *vbt_panel_init(struct intel_dsi *intel_dsi, u16 panel_id);
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c 
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 3830a4f..21a2e37 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -267,7 +267,7 @@ static void vlv_enable_dsi_pll(struct intel_encoder 
*encoder)
DRM_DEBUG_KMS("DSI PLL locked\n");
 }
 
-void vlv_disable_dsi_pll(struct intel_encoder *encoder)
+static void vlv_disable_dsi_pll(struct intel_encoder *encoder)
 {
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
u32 tmp;
@@ -284,6 +284,26 @@ void vlv_disable_dsi_pll(struct intel_encoder *encoder)
mutex_unlock(_priv->sb_lock);
 }
 
+static void bxt_disable_dsi_pll(struct intel_encoder *encoder)
+{
+   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+   u32 val;
+
+   DRM_DEBUG_KMS("\n");
+
+   val = I915_READ(BXT_DSI_PLL_ENABLE);
+   val &= ~BXT_DSI_PLL_DO_ENABLE;
+   I915_WRITE(BXT_DSI_PLL_ENABLE, val);
+
+   /*
+* PLL lock should deassert within 200us.
+* Wait up to 1ms before timing out.
+*/
+   if (wait_for((I915_READ(BXT_DSI_PLL_ENABLE)
+   & BXT_DSI_PLL_LOCKED) == 0, 1))
+   DRM_ERROR("Timeout waiting for PLL lock deassertion\n");
+}
+
 static void assert_bpp_mismatch(int pixel_format, int pipe_bpp)
 {
int bpp;
@@ -461,3 +481,13 @@ void intel_enable_dsi_pll(struct intel_encoder *encoder)
else if (IS_BROXTON(dev))
bxt_enable_dsi_pll(encoder);
 }
+
+void intel_disable_dsi_pll(struct intel_encoder *encoder)
+{
+   struct drm_device *dev = encoder->base.dev;
+
+   if (IS_VALLEYVIEW(dev))
+   vlv_disable_dsi_pll(encoder);
+   else if (IS_BROXTON(dev))
+   bxt_disable_dsi_pll(encoder);
+}
-- 
1.7.9.5

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/4] drm/i915: read sink_count dpcd always

[Jani Nikula]

On Tue, 01 Sep 2015, Sivakumar Thulasimani  
wrote:
> On 9/1/2015 3:59 PM, Jani Nikula wrote:
>> On Thu, 27 Aug 2015, Sivakumar Thulasimani  
>> wrote:
>>> From: "Thulasimani,Sivakumar" 
>>>
>>> This patch reads sink_count dpcd always and removes its
>>> read operation based on values in downstream port dpcd.
>>>
>>> SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
>>> SINK_COUNT denotes if a display is attached, while
>>> DOWNSTREAM_PORT_PRESET indicates how many ports are available
>>> in the dongle where display can be attached. so it is possible
>>> for sink count to change irrespective of value in downstream
>>> port dpcd.
>> This makes sense.
>>
>> I'm scared this may break something, if there are displays/adapters out
>> there that don't set sink count properly. I guess only one way to find
>> out... And this might actually fix something else.
>>
>>> Here is a table of possible values and scenarios
>>>
>>> sink_count  downstream_port
>>>  present
>>> 0   0   no display is attached
>>> 0   1   dongle is connected without display
>>> 1   0   display connected directly
>>> 1   1   display connected through dongle
>> Do you think you handle this last case properly now? Previously we'd
>> return with "connected" at the sink count check, but now we'll go for
>> the "pke ddc gently" phase.
>>
>> See below.
>>
>>> v2: moved out crtc enabled checks to prior patch(Jani)
>>>
>>> Signed-off-by: Sivakumar Thulasimani 
>>> ---
>>>   drivers/gpu/drm/i915/intel_dp.c |   21 -
>>>   1 file changed, 8 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index 76561e0..9e4e27d 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>>> struct drm_device *dev = dig_port->base.base.dev;
>>> struct drm_i915_private *dev_priv = dev->dev_private;
>>> uint8_t rev;
>>> +   uint8_t reg;
>>>   
>>> if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,
>>> sizeof(intel_dp->dpcd)) < 0)
>>> @@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>>> if (intel_dp->dpcd[DP_DPCD_REV] == 0)
>>> return false; /* DPCD not present */
>>>   
>>> +   if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
>>> +   , 1) < 0)
>>> +   return false;
>>> +
>>> +   if (!DP_GET_SINK_COUNT(reg))
>>> +   return false;
>>> +
>>> /* Check if the panel supports PSR */
>>> memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
>>> if (is_edp(intel_dp)) {
>>> @@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
>>> if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
>>> return connector_status_connected;
>>>   
>>> -   /* If we're HPD-aware, SINK_COUNT changes dynamically */
>>> -   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
>>> -   intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
>>> -   uint8_t reg;
>>> -
>>> -   if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
>>> -   , 1) < 0)
>>> -   return connector_status_unknown;
>>> -
>>> -   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
>>> - : connector_status_disconnected;
>>> -   }
>>> -
>> Why do we proceed here if we know that we have sink count > 0 and we
>> have a downstream port present? Admittedly I'm not sure I understand (or
>> remember) why we had this logic in the first place...
>>
>> BR,
>> Jani.
> based on what little i can dig up, we proceed in case of dongles to 
> check if the
> display is CRT or not.
> if edid read succeeded, it is DP or any display with proper edid to work 
> with.
> If edid read failed, then it could be CRT, without edid

My point is, with the current code, if we have downstream port present
and sink count > 0 and the first downsteam port supports hpd, we'll
directly say status is connected. The hpd check may be bogus, but we
still won't go probing ddc on them.

With your patch, we'd always do the ddc probe if there is a downstream
port present and the sink count > 0.

BR,
Jani.



>
> we can make it work with a fake edid, but it seems current code just
> sets it as connector_status_unknown and ignores the display
>
>>> /* If no HPD, poke DDC gently */
>>> if (drm_probe_ddc(_dp->aux.ddc))
>>> return connector_status_connected;
>>> -- 
>>> 1.7.9.5
>>>
>
> -- 
> regards,
> Sivakumar
>

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [RFC 1/3] drm/i915: Roll intel_crtc->atomic into intel_crtc_state

[Ville Syrjälä]

On Tue, Sep 01, 2015 at 08:30:05AM -0700, Matt Roper wrote:
> On Tue, Sep 01, 2015 at 07:24:19AM +0200, Maarten Lankhorst wrote:
> > Op 29-08-15 om 01:57 schreef Matt Roper:
> > > Way back at the beginning of i915's atomic conversion I added
> > > intel_crtc->atomic as a temporary dumping ground for "stuff to do
> > > outside vblank evasion" flags since CRTC states weren't properly wired
> > > up and tracked at that time.  We've had proper CRTC state tracking for a
> > > while now, so there's really no reason for this hack to continue to
> > > exist.  Moving forward we want to store intermediate crtc/plane state
> > > data for modesets in addition to the final state, so moving these fields
> > > into the proper state object allows us to properly compute them for both
> > > the intermediate and final state.
> > >
> > > Signed-off-by: Matt Roper 
> > > ---
> > Can I shoot this patch down? It's better to add a field 'wm_changed'
> > to the crtc_state, which gets reset to false for each crtc_state
> > duplication. It's needed for checking if a cs pageflip can be done for
> > atomic. It would remove the duplication of some checks there.
> > 
> > The other atomic state members will die soon. I already have some
> > patches to achieve that. :)
> > 
> > I'm not sure if an intermediate state is a good idea. Any code that
> > disables a crtc should only be looking at the old state.
> > pre_plane_update runs all stuff in preparation for disabling planes,
> > while post_plane_update runs everything needed for enabling planes. So
> > no need to split it up I think, maybe put in some intermediate
> > watermarks in intel_atomic_state, but no need for a full crtc_state.
> 
> Well, the intermediate state stuff was requested by Ville in response to
> my watermark series, so I posted these patches as an RFC to make sure I
> was understanding what he was looking for properly.
> 
> Ville, can you comment?

My opinion is that the current "disable is special" way of doing things
is quite horrible. For one it makes it really hard to reason about what
happens to a plane or crtc during the modeset. It's not just off->on,
on->off, or same->same, but can be on->off->on. With the intermediate
state in place, there can only be one transition, so really easy to
think about what's going on.

It'll also mean don't have to sprinkle silly wm update calls all over
the modeset path. They will just get updated in response to the plane
state changes. Same for IPS/FBC etc.

> 
> 
> Matt
> 
> > 
> > After a modeset disable you should be able to put in any wm value in
> > .crtc_enable because no plane will be active.
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Request Linux Graphic Driver for Intel GMA 3150

[Vivi, Rodrigo]

On Tue, 2015-09-01 at 09:59 +0300, Jani Nikula wrote:
> On Sat, 22 Aug 2015, David Ho  wrote:
> > REQUEST
> > 
> > May I please request support for driver of Intel GMA 3150 for 
> > Ubuntu 14.04.3
> > 32 bit (Trusty Tahr)?
> > 
> > I installed "Intel Graphic Installer for Linux" from 01.org, but it 
> > stops at
> > the very first step saying "Distribution not supported".
> 
> Rodrigo (Cc'd) knows this stuff better, but I don't think it's likely
> old (from upstream POV) distros will be supported. In that regard,
> you're probably better off asking help from your distro vendor.

Unfortunately Installer aims to support just latest versions of Ubuntu
and Fedora when it is being prepared for release, regardless distros
LTS.
In the past we supported LTS, but with time official updates conflicted
with installer packages and caused more issues to users.

> > BACKGROUND
> > 
> > After fresh install of 14.04, the mouse pointer is not showing up 
> > and the
> > display change (when scrolling, moving between windows, etc) is 
> > very slow
> > (even only for regular application, never tried to watch video 
> > yet). I
> > concluded that this is the driver issue.
> 
> Does it work on a newer Ubuntu install? Or can you try a new kernel? 
> If
> you can reproduce this on a new kernel, please file a bug at [1].

> BR,
> Jani.
> 
> 
> 
> [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=
> DRM/Intel
> 
> 
> > 
> > I must install it for around 20 PCs.
> > 
> > Please help me to get the correct driver.
> > 
> >  
> > 
> > Thank you.
> > 
> >  
> > 
> > Regards,
> > 
> > David Ho
> > 
> >  
> > 
> >  
> > 
> > -Original Message-
> > From: Chacn Limn, DanielX [mailto:danielx.chacn.l...@intel.com] 
> > Sent: 21 Agustus 2015 22:05
> > To: hupernikao...@gmail.com
> > Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Diaz, Victor H
> > Subject: RE: [Contact] Intel GMA 3150 for Ubuntu 14.04.3Trusty Tahr 
> > 32bit
> > 
> >  
> > 
> > Hi David,
> > 
> > Thank you for contacting us.
> > 
> >  
> > 
> > For help or more information about Linux Graphics drivers please 
> > contact the
> > Team in charge through their mailing list:
> > 
> >   
> > intel-gfx@lists.freedesktop.org
> > 
> >  
> > 
> > Regards,
> > 
> > Daniel.
> > 
> >  
> > 
> > [.MESSAGES TRUNCATED]
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

[Daniel Vetter]

On Tue, Sep 01, 2015 at 11:12:11AM -0400, Rob Clark wrote:
> On Tue, Sep 1, 2015 at 10:41 AM, Tomi Valkeinen  wrote:
> >
> >
> > On 01/09/15 17:34, Rob Clark wrote:
> >> On Tue, Sep 1, 2015 at 6:32 AM, Tomi Valkeinen  
> >> wrote:
> >>>
> >>>
> >>> On 25/08/15 22:24, Rob Clark wrote:
>  On Tue, Aug 25, 2015 at 9:45 AM, Daniel Vetter  
>  wrote:
> > When the usual fbcon legacy options are enabled we have
> > ->register_framebuffer
> >   ->fb notifier chain calls into fbcon
> > ->fbcon sets up console on new fbi
> >   ->fbi->set_par
> > ->drm_fb_helper_set_par exercises full kms api
> >
> > And because of locking inversion hilarity all of register_framebuffer
> > is done with the console lock held. Which means that the first time on
> > driver load we exercise _all_ the kms code (all probe paths and
> > modeset paths for everything connected) is under the console lock.
> > That means if anything goes belly-up in that big pile of code nothing
> > ever reaches logfiles (and the machine is dead).
> >
> > Usual tactic to debug that is to temporarily remove those console_lock
> > calls to be able to capture backtraces. I'm fed up writing this patch
> > and recompiling kernels. Hence this patch here to add an unsafe,
> > kernel-taining option to do this at runtime.
> >
> > Cc: Jean-Christophe Plagniol-Villard 
> > Cc: Tomi Valkeinen 
> > Cc: linux-fb...@vger.kernel.org
> > Signed-off-by: Daniel Vetter 
> 
>  This one was causing me some problems, if I tried to enable
>  lockless_register_fb.  It *looks* like it should work, so I'm not
>  quite sure what the deal is.  But I'm 110% fan of getting something
>  like this working, because console_lock is pretty much the bane of kms
>  developer's existence..
> 
>  I'll have to debug further on a system where I can see more than the
>  bottom three lines of the second to last backtrace..
> >>>
> >>> Any idea if anyone has ever looked at properly fixing this?
> >>
> >> I hadn't had a chance to look at it further yet..  I think Daniel
> >> claimed it worked for him, but he was probably on intel-next, where I
> >> was on drm-next at the time which seemed to be having some unrelated
> >> i915 issues (when I was trying to debug atomic fb-helper patches).  So
> >> can't really say that the issue I had was actually related to this
> >> patch.  I'll try again later this week or next, when hopefully i915 in
> >> drm-next is in better shape..
> >
> > Oh, I didn't mean this patch, but the whole console lock in general.
> > I've also banged my head to a wall because of it =).
> 
> oh, not sure.. every time I've started looking closer at
> console/console_lock I run away screaming..  I guess if it were
> possible to push the lock down further so only drivers that needed the
> lock (presumably serial/net/etc) could take it, that would be nice..
> but not sure I am that brave..

console_lock is pretty much unfixable without rewriting half of fbdev.
Which I don't expect to ever happen. For the curious look at all the
commits changing locking in fbdev over the past few years.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 1/3] drm/i915: Roll intel_crtc->atomic into intel_crtc_state

[Matt Roper]

On Tue, Sep 01, 2015 at 07:24:19AM +0200, Maarten Lankhorst wrote:
> Op 29-08-15 om 01:57 schreef Matt Roper:
> > Way back at the beginning of i915's atomic conversion I added
> > intel_crtc->atomic as a temporary dumping ground for "stuff to do
> > outside vblank evasion" flags since CRTC states weren't properly wired
> > up and tracked at that time.  We've had proper CRTC state tracking for a
> > while now, so there's really no reason for this hack to continue to
> > exist.  Moving forward we want to store intermediate crtc/plane state
> > data for modesets in addition to the final state, so moving these fields
> > into the proper state object allows us to properly compute them for both
> > the intermediate and final state.
> >
> > Signed-off-by: Matt Roper 
> > ---
> Can I shoot this patch down? It's better to add a field 'wm_changed'
> to the crtc_state, which gets reset to false for each crtc_state
> duplication. It's needed for checking if a cs pageflip can be done for
> atomic. It would remove the duplication of some checks there.
> 
> The other atomic state members will die soon. I already have some
> patches to achieve that. :)
> 
> I'm not sure if an intermediate state is a good idea. Any code that
> disables a crtc should only be looking at the old state.
> pre_plane_update runs all stuff in preparation for disabling planes,
> while post_plane_update runs everything needed for enabling planes. So
> no need to split it up I think, maybe put in some intermediate
> watermarks in intel_atomic_state, but no need for a full crtc_state.

Well, the intermediate state stuff was requested by Ville in response to
my watermark series, so I posted these patches as an RFC to make sure I
was understanding what he was looking for properly.

Ville, can you comment?


Matt

> 
> After a modeset disable you should be able to put in any wm value in
> .crtc_enable because no plane will be active.

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Clear PIPE.STAT before IIR on VLV/CHV

[Imre Deak]

On pe, 2015-08-14 at 18:24 +0100, Chris Wilson wrote:
> The PIPE.STAT register contains some interrupt status bits per pipe, and
> if assert cause the corresponding bit in the IIR to be asserted (thus
> raising an interrupt). When handling an interrupt, we should clear the
> PIPE.STAT generator first before clearing the IIR so that we do not miss
> events or cause spurious work.
> 
> This ordering was broken by
> 
> commit 27b6c122512ca30399bb1b39cc42eda83901f304
> Author: Oscar Mateo 
> Date:   Mon Jun 16 16:11:00 2014 +0100
> 
> drm/i915/chv: Ack interrupts before handling them (CHV)
> 
> commit 3ff60f89bc4836583f5bd195062f16c563bd97aa
> Author: Oscar Mateo 
> Date:   Mon Jun 16 16:10:58 2014 +0100
> 
> drm/i915/vlv: Ack interrupts before handling them (VLV)
> 
> in attempting to reduce the amount of work done between receiving an
> interrupt and acknowledging it. In light of this motivation, split the
> pipestat interrupt handler into two, one to acknowledge and clear the
> interrupt and a later pass to process it.

Yes, after thinking about hierarchical interrupt clearing/handling this
makes complete sense. It was even hinted at by Ville in the discussion
of the above patches, but I missed his point back then.

> Signed-off-by: Chris Wilson 
> Cc: Oscar Mateo 
> Cc: Bob Beckett 
> Cc: Imre Deak 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 55 
> +++--
>  1 file changed, 31 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 66064511cffb..92bdfe6f91d8 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1457,24 +1457,21 @@ static void gen6_rps_irq_handler(struct 
> drm_i915_private *dev_priv, u32 pm_iir)
>   }
>  }
>  
> -static bool intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
> +static inline bool
> +intel_pipe_handle_vblank(struct drm_device *dev, enum pipe pipe)
>  {
> - if (!drm_handle_vblank(dev, pipe))
> - return false;
> -
> - return true;
> + return drm_handle_vblank(dev, pipe);
>  }
>  
> -static void valleyview_pipestat_irq_handler(struct drm_device *dev, u32 iir)
> +static void valleyview_pipestat_irq_get(struct drm_i915_private *dev_priv,
> + u32 iir, u32 *pipe_stats)
>  {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - u32 pipe_stats[I915_MAX_PIPES] = { };
>   int pipe;
>  
>   spin_lock(_priv->irq_lock);
>   for_each_pipe(dev_priv, pipe) {
> + u32 mask, val, iir_bit = 0;
>   int reg;
> - u32 mask, iir_bit = 0;
>  
>   /*
>* PIPESTAT bits get signalled even when the interrupt is
> @@ -1486,6 +1483,7 @@ static void valleyview_pipestat_irq_handler(struct 
> drm_device *dev, u32 iir)
>  
>   /* fifo underruns are filterered in the underrun handler. */
>   mask = PIPE_FIFO_UNDERRUN_STATUS;
> + mask |= PIPESTAT_INT_ENABLE_MASK;
>  
>   switch (pipe) {
>   case PIPE_A:
> @@ -1501,21 +1499,25 @@ static void valleyview_pipestat_irq_handler(struct 
> drm_device *dev, u32 iir)
>   if (iir & iir_bit)
>   mask |= dev_priv->pipestat_irq_mask[pipe];
>  
> - if (!mask)
> - continue;
> -
>   reg = PIPESTAT(pipe);
> - mask |= PIPESTAT_INT_ENABLE_MASK;
> - pipe_stats[pipe] = I915_READ(reg) & mask;
> + val = I915_READ(reg);
> + pipe_stats[pipe] |= val & mask;
>  
>   /*
>* Clear the PIPE*STAT regs before the IIR
>*/
> - if (pipe_stats[pipe] & (PIPE_FIFO_UNDERRUN_STATUS |
> - PIPESTAT_INT_STATUS_MASK))
> - I915_WRITE(reg, pipe_stats[pipe]);
> + if (val & (PIPE_FIFO_UNDERRUN_STATUS |
> +PIPESTAT_INT_STATUS_MASK))
> + I915_WRITE(reg, val);
>   }
>   spin_unlock(_priv->irq_lock);
> +}
> +
> +static void valleyview_pipestat_irq_handler(struct drm_i915_private 
> *dev_priv,
> + u32 *pipe_stats)
> +{
> + struct drm_device *dev = dev_priv->dev;
> + int pipe;
>  
>   for_each_pipe(dev_priv, pipe) {
>   if (pipe_stats[pipe] & PIPE_START_VBLANK_INTERRUPT_STATUS &&
> @@ -1578,6 +1580,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
> *arg)
>  {
>   struct drm_device *dev = arg;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> + u32 pipe_stats[I915_MAX_PIPES] = {};
>   u32 iir, gt_iir, pm_iir;
>   irqreturn_t ret = IRQ_NONE;
>  
> @@ -1600,6 +1603,7