Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

2016-02-14 Thread Oleksandr Natalenko 

Hi, Ville.

13.02.2016 01:23, Ville Syrjälä wrote:

Few other ideas:
- Was the monitor sleeping when you tried this? Can you maybe push
  some button on it and then immediately run the intel_reg read command
  again?


Nope. It just goes to sleep mode after (I suppose) drm module is loaded. 
Before module gets loaded monitor displays console as it should and does 
not sleep. However, I've tried to switch monitor inputs as well as 
pushing power button with no luck.



- Do you have another monitor to try?
- Do you have another cable to try?


Will find that.


- Maybe the pullup/down on the hpd line is misconfigured or something.
  Any chance of updating the BIOS on the machine?


===
Base Board Information
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: H61M-K
BIOS Information
Vendor: American Megatrends Inc.
Version: 0801
Release Date: 07/21/2014
===

0801 is the latest available for this board.


- What does 'intel_reg read 0xc2000 0xc2004 0xc2020' say?


===
(0x000c2000): 0x
(0x000c2004): 0x0001
(0x000c2020): 0x60004000
===


- The spec claims the TMDS vs. SDVO select has something to do with
  hpd generation. I can't see any difference on my IVB though, so not
  sure it's really true.

  What does 'intel_reg read 0xe1140 0xe1150 0xe1160' tell us?


===
  HDMIB (0x000e1140): 0x0018 (disabled 
pipe A 8bpc SDVO DVI audio disabled +vsync +hsync non-detected)
  HDMIC (0x000e1150): 0x0804 (disabled 
pipe A 8bpc TMDS DVI audio disabled -vsync -hsync detected)
  HDMID (0x000e1160): 0x0018 (disabled 
pipe A 8bpc SDVO DVI audio disabled +vsync +hsync non-detected)

===


  Let's try these anyway (with the cable plugged in):

  intel_reg write 0xe1140 0x0
  intel_reg write 0xe1150 0x0
  intel_reg write 0xe1160 0x0
  sleep 1
  intel_reg read 0xc4000

  intel_reg write 0xe1140 0x800
  intel_reg write 0xe1150 0x800
  intel_reg write 0xe1160 0x800
  sleep 1
  intel_reg read 0xc4000

  intel_reg write 0xe1140 0x800800
  intel_reg write 0xe1150 0x800800
  intel_reg write 0xe1160 0x800800
  sleep 1
  intel_reg read 0xc4000

  intel_reg write 0xe1140 0x80
  intel_reg write 0xe1150 0x80
  intel_reg write 0xe1160 0x80
  sleep 1
  intel_reg read 0xc4000



Same output for all 4 sets of commands:

===
(0x000c4000): 0x
===

Regards,
  Oleksandr.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

2016-02-14 Thread R, Durgadoss 
Hi Ville,

>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Friday, February 12, 2016 10:43 PM
>To: R, Durgadoss 
>Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
>
>Subject: Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link 
>training for typeC DP support on
>BXT
>
>On Mon, Feb 01, 2016 at 07:27:53PM +0530, Durgadoss R wrote:
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the DP panel as well as number
>> of lanes that can be supported by the type-C cable. Sometimes, the
>> type-C cable may limit the bandwidth even if Panel can support
>> more lanes. To address these scenarios, the display driver will
>> start link training with max lanes, and if that fails, the driver
>> falls back to x2 lanes; and repeats this procedure for all
>> bandwidth/lane configurations.
>>
>> * Since link training is done before modeset only the port
>>   (and not pipe/planes) and its associated PLLs are enabled.
>> * On DP hotplug: Directly start link training on the crtc
>>   associated with the DP encoder.
>> * On Connected boot scenarios: When booted with an LFP and a DP,
>>   typically, BIOS brings up DP. In these cases, we disable the
>>   crtc, do upfront link training and then re-enable it back.
>> * All local changes made for upfront link training are reset
>>   to their previous values once it is done; so that the
>>   subsequent modeset is not aware of these changes.
>
>Glancing over this stuff, it doesn't look all that good on the locking
>front. Mainly there doesn't seem to locking.
>
>In general I'm not really convinced upfront link training is a very good
>idea if it needs a pipe. What happens if we fail to find a free pipe?
>
>I'd be much happier about this if we could make do without a pipe at

We actually don't enable/disable the pipe. We need the crtc structures
because values like port clock/link bw/dpll hw state are stored in
crtc->config structures. This is why we had to touch crtc related
data structures.

Ander has pulled the dpll_hw_states out of crtc structures and made them
independent. With this, things should improve.. I need to try this
implementation to see if we can/can't completely get away
with modifying crtc structures.

>least on some modern platforms and actually limit the feature to
>those platforms. PLLs are another concern, but I think modern platforms
>often have some kind of way to always get the standard DP frequencies
>from eg. the LCPLL.
>
>If we do go with the "hope you find a free pipe" approach, then it
>really needs to do that atomic locking stuff right. Otherwise I'd expect

Yes, we missed it. Ander pointed out the place where we need this
locking. So, we will re-work this.

Thanks,
Durga

>fireworks when someone plugs in a display while there's modeset
>happening.
>
>--
>Ville Syrjälä
>Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv2 2/4] drm/i915: Make finding unused crtc as a generic function

2016-02-14 Thread R, Durgadoss 
>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Friday, February 12, 2016 10:23 PM
>To: R, Durgadoss ; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCHv2 2/4] drm/i915: Make finding unused crtc as a 
>generic function
>
>On Mon, 2016-02-01 at 19:27 +0530, Durgadoss R wrote:
>> Looping over the crtc list and finding an unused crtc
>> has users other than load_detect().
>
>Which other users? If there are other users they should be converted in this
>patch. If the use will only come in a future patch, please make that clear in
>the commit message.

Thanks for the comments, Will update this patch with comments,
And send as part of next version.

Thanks,
Durga

>
>> Hence move it to
>> a common function so that we can re-use the logic.
>>
>> Signed-off-by: Durgadoss R 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 37 
>> ++-
>> -
>>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>>  2 files changed, 24 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 92cd5c6..af50e61 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -10417,6 +10417,27 @@ static int intel_modeset_setup_plane_state(struct
>> drm_atomic_state *state,
>>  return 0;
>>  }
>>
>> +struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder)
>> +{
>
>This function is exported, so it needs some kernel doc.
>
>> +struct drm_crtc *possible_crtc;
>> +struct drm_crtc *crtc = NULL;
>> +struct drm_device *dev = encoder->dev;
>> +int i = -1;
>> +
>> +for_each_crtc(dev, possible_crtc) {
>> +i++;
>> +if (!(encoder->possible_crtcs & (1 << i)))
>> +continue;
>> +if (possible_crtc->state->enable)
>> +continue;
>> +
>> +crtc = possible_crtc;
>> +break;
>> +}
>> +
>> +return crtc;
>> +}
>> +
>>  bool intel_get_load_detect_pipe(struct drm_connector *connector,
>>  struct drm_display_mode *mode,
>>  struct intel_load_detect_pipe *old,
>> @@ -10425,7 +10446,6 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  struct intel_crtc *intel_crtc;
>>  struct intel_encoder *intel_encoder =
>>  intel_attached_encoder(connector);
>> -struct drm_crtc *possible_crtc;
>>  struct drm_encoder *encoder = _encoder->base;
>>  struct drm_crtc *crtc = NULL;
>>  struct drm_device *dev = encoder->dev;
>> @@ -10434,7 +10454,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  struct drm_atomic_state *state = NULL;
>>  struct drm_connector_state *connector_state;
>>  struct intel_crtc_state *crtc_state;
>> -int ret, i = -1;
>> +int ret;
>>
>>  DRM_DEBUG_KMS("[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
>>connector->base.id, connector->name,
>> @@ -10476,21 +10496,10 @@ retry:
>>  return true;
>>  }
>>
>> -/* Find an unused one (if possible) */
>> -for_each_crtc(dev, possible_crtc) {
>> -i++;
>> -if (!(encoder->possible_crtcs & (1 << i)))
>> -continue;
>> -if (possible_crtc->state->enable)
>> -continue;
>> -
>> -crtc = possible_crtc;
>> -break;
>> -}
>> -
>>  /*
>>   * If we didn't find an unused CRTC, don't use any.
>>   */
>> +crtc = intel_get_unused_crtc(encoder);
>
>The comment above looks out of place now. It is pretty obvious anyway, so maybe
>just delete it.
>
>With those fixed, this is
>
>Reviewed-by: Ander Conselvan de Oliveira 
>
>   if (!crtc) {
>>  DRM_DEBUG_KMS("no pipe available for load-detect\n");
>>  goto fail;
>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>> b/drivers/gpu/drm/i915/intel_drv.h
>> index c7a6e32..9fe7c4b 100644
>> --- a/drivers/gpu/drm/i915/intel_drv.h
>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>> @@ -1106,6 +1106,7 @@ bool intel_get_load_detect_pipe(struct drm_connector
>> *connector,
>>  void intel_release_load_detect_pipe(struct drm_connector *connector,
>>  struct intel_load_detect_pipe *old,
>>  struct drm_modeset_acquire_ctx *ctx);
>> +struct drm_crtc *intel_get_unused_crtc(struct drm_encoder *encoder);
>>  int intel_pin_and_fence_fb_obj(struct drm_plane *plane,
>> struct drm_framebuffer *fb,
>> const struct drm_plane_state *plane_state);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

2016-02-14 Thread R, Durgadoss 
>-Original Message-
>From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
>Sent: Friday, February 12, 2016 10:13 PM
>To: R, Durgadoss ; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link 
>training for typeC DP support on
>BXT
>
>On Mon, 2016-02-01 at 19:27 +0530, Durgadoss R wrote:
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the DP panel as well as number
>> of lanes that can be supported by the type-C cable. Sometimes, the
>> type-C cable may limit the bandwidth even if Panel can support
>> more lanes. To address these scenarios, the display driver will
>> start link training with max lanes, and if that fails, the driver
>> falls back to x2 lanes; and repeats this procedure for all
>> bandwidth/lane configurations.
>>
>> * Since link training is done before modeset only the port
>>   (and not pipe/planes) and its associated PLLs are enabled.
>> * On DP hotplug: Directly start link training on the crtc
>>   associated with the DP encoder.
>> * On Connected boot scenarios: When booted with an LFP and a DP,
>>   typically, BIOS brings up DP. In these cases, we disable the
>>   crtc, do upfront link training and then re-enable it back.
>> * All local changes made for upfront link training are reset
>>   to their previous values once it is done; so that the
>>   subsequent modeset is not aware of these changes.
>>
>
>Please always include a changelog when sending a new version of a patch.

Sure, will add it in the next version.

>
>> Signed-off-by: Durgadoss R 
>> ---
>>  drivers/gpu/drm/i915/intel_ddi.c | 102 +
>>  drivers/gpu/drm/i915/intel_display.c |  38 ++-
>>  drivers/gpu/drm/i915/intel_dp.c  | 122 
>> ++
>> -
>>  drivers/gpu/drm/i915/intel_drv.h |  10 +++
>>  4 files changed, 270 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 3fb9a03..cc5cad5 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3217,6 +3217,108 @@ intel_ddi_init_hdmi_connector(struct
>> intel_digital_port *intel_dig_port)
>>  return connector;
>>  }
>>
>> +static void intel_ddi_commit_upfront_pll_config(struct intel_dp *intel_dp,
>> +struct intel_shared_dpll *pll)
>> +{
>> +struct intel_shared_dpll_config tmp_config;
>> +
>> +/*
>> + * The shared_dpll_config is computed in intel_get_shared_dpll().
>> + * It is committed to 'pll->config' here to be used in
>> + * intel_enable/disable_shared_dpll functions. Before committing.
>> + * save the existing config, so that once upfront link training is
>> + * done, the original value of 'pll->config' can be restored.
>> + */
>> +tmp_config = pll->config;
>> +pll->config = intel_dp->upfront_pll_config;
>> +intel_dp->upfront_pll_config = tmp_config;
>> +}
>> +
>> +static struct intel_shared_dpll *intel_ddi_select_upfront_pll_config(
>> +struct intel_dp *intel_dp, struct intel_crtc *crtc)
>> +{
>> +if (!intel_ddi_pll_select(crtc, crtc->config))
>> +return NULL;
>> +
>> +return intel_crtc_to_shared_dpll(crtc);
>> +}
>> +
>> +static void intel_ddi_clear_upfront_pll_config(struct intel_dp *intel_dp,
>> +struct intel_shared_dpll *pll)
>> +{
>> +pll->config = intel_dp->upfront_pll_config;
>> +}
>> +
>
>The shared pll interface is really getting in the way here. And BXT plls aren't
>even shared. We are jumping through hoops to get the pll that matches the given
>encoder and to call the code that calculates the dpll_hw_state based on the DP
>link rate. I'd like to get that interface fixed but I reckon it will be tricky
>to find something that works for all the platforms we support. That's the next
>thing on my todo list.
>
>If we have to live with some intermediary solution, I think it would be better
>to (almost) completely bypass the shared dpll stuff. First we would need to
>split bxt_ddi_pll_sel() so that we would have a function that takes the link
>bandwidth and spits out a dpll_hw_state without looking at crtc_state. Then we
>would just take the right pll based on dig_port->port, make sure it is not 
>being
>used and program it with the hw state we get from that new function.
>
>I wrote a patch to do that split. With it, the PLL enable logic in the upfront
>link train logic would look a bit like below. There is some potential for
>problems with the state checker, but it should be fine as long as the old dpll

This is similar to what we had in the earlier version except the
ddi_pll_select split.. I moved it this way because we wanted all the
dpll functionality within the dpll interfaces. But yes, as you said,
we could not get the whole thing cleaner.

Re: [Intel-gfx] 4.3.3 / skylake / dual graphics: multiple CSR errors at boot from i915 driver

2016-02-14 Thread Zhi Wang 
From SKL, i915 will try to load DMC firmware when system is starting 
up. You can find it from 01.org. Personally, it looks without the 
firmware, the system is also able to work, except a lot warnings. :)


On 02/13/16 08:42, Marc MERLIN wrote:

I'm testing a new thinkpad skylake based P70 with dual graphics
legolas:~# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Device 191b (rev 06)
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] 
(rev a2)


I'm getting these warnings at boot, although X11 seems to come up ok.

Should I worry about them?
WARNING: CPU: 4 PID: 101 at drivers/gpu/drm/i915/intel_csr.c:458 
assert_csr_loaded+0x2e/0xbe()
CSR is not loaded.
Modules linked in: rtsx_pci_ms(+) snd_hda_intel rtsx_pci_sdmmc memstick 
iTCO_wdt iTCO_vendor_support snd_hda_codec snd_hda_core snd_hwdep snd_pcm_oss 
snd_mixer_oss intel_rapl snd_pcm iosf_mbi thinkpad_acpi x86_pkg_temp_thermal 
nvram intel_powerclamp coretemp snd_seq_midi snd_seq_midi_event kvm_intel 
snd_rawmidi kvm snd_seq crct10dif_pclmul crc32_pclmul snd_seq_device ttm 
snd_timer iwlwifi microcode input_leds snd nvidiafb xhci_pci psmouse pcspkr 
vgastate serio_raw xhci_hcd cfg80211 i2c_i801 rtsx_pci sg soundcore fb_ddc 
wmi(+) usbcore rfkill battery ac tpm_crb(+) usb_common tpm fjes evdev shpchp 
processor sata_sil24 r8169 mii fuse fan raid456 multipath mmc_block mmc_core 
dm_crypt dm_mod async_raid6_recov async_pq async_xor async_memcpy async_tx 
blowfish_x86_64 blowfish_common ecb xts crc32c_intel
  aesni_intel e1000e aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd ptp 
pps_core thermal
CPU: 4 PID: 101 Comm: kworker/4:1 Not tainted 
4.3.3-amd64-i915-volpreempt-20150421 #2
Hardware name: LENOVO 20ERCTO1WW/20ERCTO1WW, BIOS N1DET41W (1.15 ) 12/31/2015
ahci :00:17.0: port does not support device sleep
Workqueue: events azx_probe_work [snd_hda_intel]
   88087aebbc48 8134150e 88087aebbc90
  88087aebbc80 8105aa29 8146f5ee 88087ad5
  81cd81d0 300f 88087ad45800 88087aebbce8
Call Trace:
  [] dump_stack+0x44/0x55
  [] warn_slowpath_common+0x99/0xb2
  [] ? assert_csr_loaded+0x2e/0xbe
  [] warn_slowpath_fmt+0x48/0x50
  [] ? mutex_lock+0x12/0x2f
  [] ? mutex_unlock+0x16/0x18
  [] assert_csr_loaded+0x2e/0xbe
  [] skl_set_power_well+0x198/0x7df
  [] skl_power_well_enable+0x13/0x15
  [] intel_display_power_get+0x9e/0xc9
  [] i915_audio_component_get_power+0x1e/0x20
  [] snd_hdac_display_power+0x91/0xf1 [snd_hda_core]
  [] azx_probe_continue+0xa9/0x654 [snd_hda_intel]
  [] ? finish_task_switch+0xb0/0x13b
  [] azx_probe_work+0x15/0x17 [snd_hda_intel]
  [] process_one_work+0x15b/0x260
  [] worker_thread+0x1f0/0x29d
  [] ? rescuer_thread+0x281/0x281
  [] ? rescuer_thread+0x281/0x281
  [] kthread+0xa5/0xad
  [] ? kthread_parkme+0x24/0x24
  [] ret_from_fork+0x3f/0x70
  [] ? kthread_parkme+0x24/0x24
---[ end trace 904c3d98e9b53001 ]---
[ cut here ]
WARNING: CPU: 4 PID: 101 at drivers/gpu/drm/i915/intel_csr.c:461 
assert_csr_loaded+0x8c/0xbe()
CSR SSP Base Not fine
Modules linked in: rtsx_pci_ms(+) snd_hda_intel rtsx_pci_sdmmc memstick 
iTCO_wdt iTCO_vendor_support snd_hda_codec snd_hda_core snd_hwdep snd_pcm_oss 
snd_mixer_oss intel_rapl snd_pcm iosf_mbi thinkpad_acpi x86_pkg_temp_thermal 
nvram intel_powerclamp coretemp snd_seq_midi snd_seq_midi_event kvm_intel 
snd_rawmidi kvm snd_seq crct10dif_pclmul crc32_pclmul snd_seq_device ttm 
snd_timer iwlwifi microcode input_leds snd nvidiafb xhci_pci psmouse pcspkr 
vgastate serio_raw xhci_hcd cfg80211 i2c_i801 rtsx_pci sg soundcore fb_ddc 
wmi(+) usbcore rfkill battery ac tpm_crb(+) usb_common tpm fjes evdev shpchp 
processor sata_sil24 r8169 mii fuse fan raid456 multipath mmc_block mmc_core 
dm_crypt dm_mod async_raid6_recov async_pq async_xor async_memcpy async_tx 
blowfish_x86_64 blowfish_common ecb xts crc32c_intel
  aesni_intel e1000e aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd ptp 
pps_core thermal
CPU: 4 PID: 101 Comm: kworker/4:1 Tainted: GW   
4.3.3-amd64-i915-volpreempt-20150421 #2
Hardware name: LENOVO 20ERCTO1WW/20ERCTO1WW, BIOS N1DET41W (1.15 ) 12/31/2015
Workqueue: events azx_probe_work [snd_hda_intel]
   88087aebbc48 8134150e 88087aebbc90
  88087aebbc80 8105aa29 8146f64c 88087ad5
  81cd81d0 300f 88087ad45800 88087aebbce8
Call Trace:
  [] dump_stack+0x44/0x55
  [] warn_slowpath_common+0x99/0xb2
  [] ? assert_csr_loaded+0x8c/0xbe
  [] warn_slowpath_fmt+0x48/0x50
  [] ? gen9_read32+0x1b4/0x1c2
  [] assert_csr_loaded+0x8c/0xbe
  [] skl_set_power_well+0x198/0x7df
  [] skl_power_well_enable+0x13/0x15
  [] intel_display_power_get+0x9e/0xc9
  [] i915_audio_component_get_power+0x1e/0x20
  [] snd_hdac_display_power+0x91/0xf1 [snd_hda_core]
  [] azx_probe_continue+0xa9/0x654 [snd_hda_intel]
  [] ? finish_task_switch+0xb0/0x13b
  []

[Intel-gfx] [Regression report] Weekly regression report WW07

2016-02-14 Thread jairo . daniel . miramontes . caton 
WW07 Regression report.

Last week's regressions
+---+--+-+---+
| BugId | Summary  |Created on   
|Bisect |
+---+--+-+---+
| 94079 | [BAT regression] snd-hda blows up in module  | 2016-02-10 16:27:26 
|No |
+---+--+-+---+

Previous regressions
+---+--+-+---+
| BugId | Summary  |Created on   
|Bisect |
+---+--+-+---+
| 93971 | video framerate performance regression with  | 2016-02-02 20:11:02 
|No |
| 93802 | [IVB bisected] switching to tty1 causes fifo | 2016-01-20 20:48:09 
|Yes|
| 93698 | [BAT BYT regression] WARNING Unclaimed reg   | 2016-01-13 13:29:56 
|No |
| 93640 | [BAT ILK SNB IVB bisected] Fifo underruns si | 2016-01-08 08:43:33 
|Yes|
| 93608 | bisected: i915 SNB modeset crash in ac9b8236 | 2016-01-06 15:40:51 
|Yes|
| 93509 | [SNB] [4.4 regression] vblank wait timed out | 2015-12-26 10:54:43 
|No |
| 93393 | Regression for Skylake modesetting in kernel | 2015-12-16 07:27:52 
|No |
| 93263 | 945GM regression since 4.3   | 2015-12-05 17:55:50 
|No |
| 93122 | [SNB BAT IGT regression] pm_rpm started skip | 2015-11-26 13:35:39 
|No |
| 92972 | Black screen on Intel NUC hardware (i915) po | 2015-11-16 21:54:43 
|No |
| 92655 | [i915] LVDS screen half garbled. unable to b | 2015-10-23 20:42:24 
|Yes|
| 92575 | [4.2 regression] Massive graphics corruption | 2015-10-21 17:27:09 
|No |
| 92502 | [SKL] [Regression] igt/kms_flip/2x-flip-vs-e | 2015-10-16 15:44:30 
|No |
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will | 2015-10-10 17:26:57 
|Yes|
| 92237 | Horrible noise (audio) via DisplayPort [regr | 2015-10-02 09:07:52 
|No |
| 92096 | regression/bug introduced by commit [0e572fe | 2015-09-24 02:07:37 
|No |
| 92083 | [regression] [git pull] drm for 4.3  | 2015-09-23 03:31:34 
|No |
| 92050 | [regression]/bug introduced by commit [0e572 | 2015-09-19 19:12:23 
|No |
| 91974 | [bisected] unrecoverable black screen after  | 2015-09-11 09:33:35 
|Yes|
| 91959 | [865g 3.19 regression] Desktop image is dist | 2015-09-10 13:32:37 
|No |
| 91952 | [Bisected Regression] Blank screen from boot | 2015-09-10 01:24:00 
|Yes|
| 91844 | [HSW Regression] intel_do_flush_locked faile | 2015-09-02 00:06:09 
|No |
| 91378 | [hsw dp regression] 06ea66b6 (5.4GHz link cl | 2015-07-17 21:55:21 
|No |
| 90994 | [BDW regression] pm_rpm subtests fail and gi | 2015-06-16 18:30:52 
|No |
| 90808 | [BDW Bisected]igt/gem_ctx_param_basic/invali | 2015-06-02 03:07:02 
|Yes|
| 90732 | [BDW/BSW Bisected]igt/gem_reloc_vs_gpu/forke | 2015-05-29 02:19:26 
|Yes|
| 90368 | [SNB BSW SKL] bisected igt/kms_3d has hardco | 2015-05-08 07:28:55 
|Yes|
| 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_ | 2015-04-22 05:07:28 
|Yes|
| 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Por | 2015-04-20 07:25:42 
|Yes|
| 89872 | [ HSW Bisected ] VGA was white screen when r | 2015-04-02 11:30:59 
|Yes|
| 89728 | [HSW/BDW/BSW/BYT bisected] igt / pm_rps / re | 2015-03-23 10:01:57 
|Yes|
| 89632 | [i965 regression]igt/kms_universal_plane/uni | 2015-03-18 06:45:02 
|No |
| 89629 | [i965 regression]igt/kms_rotation_crc/sprite | 2015-03-18 06:10:53 
|No |
| 89334 | [945 regression] 4.0-rc1 kernel GPU hang:  e | 2015-02-26 08:05:08 
|No |
| 88439 | [BDW Bisected]igt/gem_reloc_vs_gpu/forked-fa | 2015-01-15 06:02:18 
|Yes|
| 88124 | i915: regression: after DP connected monitor | 2015-01-15 06:02:18 
|No |
| 87726 | [BDW Bisected] OglDrvCtx performance reduced | 2014-12-26 01:21:55 
|Yes|
| 87725 | [BDW Bisected] OglBatch7 performance reduced | 2014-12-26 01:03:12 
|Yes|
| 87662 | [ALL 3.18 Bisected] DVI --rotation inverted  | 2014-12-24 03:13:20 
|Yes|
| 87131 | [PNV regression] igt/gem_exec_lut_handle tak | 2014-12-09 03:06:30 
|No |
| 84974 | [VLV eDP-LVDS bisected] powerdomains: Screen | 2014-10-14 05:11:02 
|Yes|
| 84855 | [ILK regression]igt kms_rotation_crc/sprite- | 2014-10-10 03:21:52 
|No |
| 81537 | [snb dp regression] dp retry forever due to  | 2014-07-19 14:51:21 
|No |
| 72782 | [945GM bisected] screen blank on S3 resume o | 2013-12-17 10:02:50 
|Yes|
+---+--+-+---+

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

[Intel-gfx] Updated drm-intel-testing

2016-02-14 Thread Daniel Vetter 
Hi all,

New -testing cycle with cool stuff:
- lots and lots of fbc work from Paulo
- max pixel clock checks from Mika Kahola
- prep work for nv12 offset handling from Ville
- piles of small fixes and refactorings all around

Happy testing!

Cheers, Daniel

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

Re: [Intel-gfx] [PATCH v10 3/4] drm/i915: Set aux.dev to the drm_connector device, instead of drm_device.

2016-02-14 Thread Daniel Vetter 
On Fri, Feb 12, 2016 at 10:28:28PM +0200, Imre Deak wrote:
> On Thu, 2016-01-21 at 15:10 -0800, Rafael Antognolli wrote:
> > So far, the i915 driver and some other drivers set it to the
> > drm_device,
> > which doesn't allow one to know which DP a given aux channel is
> > related
> > to. Changing this to be the drm_connector provides proper nesting,
> > still
> > allowing one to get the drm_device from it. Some drivers already set
> > it
> > to the drm_connector.
> > 
> > This also removes the need to add a sysfs link for the i2c device
> > under
> > the connector, as it will already be there.
> 
> Yes, having the i2c-dev only at one place under the connector is more
> logical and what we want imo. It's an ABI change but if other drivers
> already have it in this way then I assume it's fine. For HDMI
> connectors we still have them under the drm_device (and there is no
> symlink for them under the connector device) but this was inconsistent
> already before this patch and can be fixed up later.
> 
> Adding Jani, in case he has comments on this.
> 
> Below one more comment:
> 
> > v9:
> >  - As a side effect, drm_dp_aux_unregister() must be called before
> >  intel_connector_unregister(), as both the aux.dev and the i2c
> > adapter
> >  dev are children of the drm_connector device now. Calling
> >  drm_dp_aux_unregister() before prevents them from being destroyed
> >  twice.
> > 
> > v10:
> >  - move aux_fini() to connector_unregister(), instead of moving
> >  drm_dp_aux_unregister() outside of connector_register().
> > 
> > Signed-off-by: Rafael Antognolli 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 18 ++
> >  1 file changed, 2 insertions(+), 16 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index e2bea710..da704c6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1188,7 +1188,6 @@ intel_dp_aux_fini(struct intel_dp *intel_dp)
> >  static int
> >  intel_dp_aux_init(struct intel_dp *intel_dp, struct intel_connector
> > *connector)
> >  {
> > -   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> >     struct intel_digital_port *intel_dig_port =
> > dp_to_dig_port(intel_dp);
> >     enum port port = intel_dig_port->port;
> >     int ret;
> > @@ -1199,7 +1198,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp,
> > struct intel_connector *connector)
> >     if (!intel_dp->aux.name)
> >     return -ENOMEM;
> >  
> > -   intel_dp->aux.dev = dev->dev;
> > +   intel_dp->aux.dev = connector->base.kdev;
> >     intel_dp->aux.transfer = intel_dp_aux_transfer;
> >  
> >     DRM_DEBUG_KMS("registering %s bus for %s\n",
> > @@ -1214,16 +1213,6 @@ intel_dp_aux_init(struct intel_dp *intel_dp,
> > struct intel_connector *connector)
> >     return ret;
> >     }
> >  
> > -   ret = sysfs_create_link(>base.kdev->kobj,
> > -   _dp->aux.ddc.dev.kobj,
> > -   intel_dp->aux.ddc.dev.kobj.name);
> > -   if (ret < 0) {
> > -   DRM_ERROR("sysfs_create_link() for %s failed
> > (%d)\n",
> > -     intel_dp->aux.name, ret);
> > -   intel_dp_aux_fini(intel_dp);
> > -   return ret;
> > -   }
> > -
> >     return 0;
> >  }
> >  
> > @@ -1232,9 +1221,7 @@ intel_dp_connector_unregister(struct
> > intel_connector *intel_connector)
> >  {
> >     struct intel_dp *intel_dp =
> > intel_attached_dp(_connector->base);
> >  
> > -   if (!intel_connector->mst_port)
> > -   sysfs_remove_link(_connector->base.kdev->kobj,
> > -     intel_dp->aux.ddc.dev.kobj.name);
> > +   intel_dp_aux_fini(intel_dp);
> 
> Hrm, the mst_port check seems to have been misplaced at some point,
> this function isn't called for virtual MST connectors. So I think it's
> fine to remove it. The patch looks ok:
> 
> Reviewed-by: Imre Deak 

Added to drm-misc, thanks.
-Daniel

> 
> >     intel_connector_unregister(intel_connector);
> >  }
> >  
> > @@ -4868,7 +4855,6 @@ void intel_dp_encoder_destroy(struct
> > drm_encoder *encoder)
> >     struct intel_digital_port *intel_dig_port =
> > enc_to_dig_port(encoder);
> >     struct intel_dp *intel_dp = _dig_port->dp;
> >  
> > -   intel_dp_aux_fini(intel_dp);
> >     intel_dp_mst_encoder_cleanup(intel_dig_port);
> >     if (is_edp(intel_dp)) {
> >     cancel_delayed_work_sync(_dp->panel_vdd_work);
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 10/12] drm/i915: Defer probe if gmux is present but its driver isn't

2016-02-14 Thread Daniel Vetter 
On Sun, Feb 14, 2016 at 1:10 PM, Lukas Wunner  wrote:
>  /**
> + * vga_switcheroo_client_probe_defer() - whether to defer probing a given GPU
> + * @pdev: pci device of GPU
> + *
> + * Determine whether any prerequisites are not fulfilled to probe a given 
> GPU.

I'd phrase this as "Determine whether the vgaswitcheroor support is
fully loaded" and drop the GPU part - it could be needed by snd
drivers eventually too.

> + * DRM drivers should invoke this early on in their ->probe callback and 
> return
> + * %-EPROBE_DEFER if it evaluates to %true. The GPU need not be registered 
> with
> + * vga_switcheroo_register_client() beforehand.

s/need not/must not/ ... is your native language German by any chance?

Aside from that ... should vga_switcheroo_register_client call this
helper instead directly and return the appropriate -EDEFER_PROBE
error? I realize for some drivers it might be way too late to unrol
from that point on, but e.g. i915 already uses -EDEFER_PROBE. And
calling it unconditionally will make sure that it's easier to notice
when people forget this. So maybe call it both from the register
functions, and export as a separate hook? And for i915 we should be
able to remove that early check entirely.

> + *
> + * Return: %false unless one of the following applies:
> + *
> + * * On pre-retina MacBook Pros, the apple-gmux driver is needed to 
> temporarily
> + *   switch DDC to the inactive GPU so that it can probe the panel's EDID.
> + *   Therefore return %true if gmux is built into the machine, @pdev is the
> + *   inactive GPU and the apple-gmux driver has not registered its handler
> + *   flags, signifying it has not yet loaded or has not finished 
> initializing.

I think the apple-specific comment here should be a separate comment
right above the if condition below - it doesn't explain the interface,
only one specific case. And we might grow more of those.
-Daniel

> + */
> +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev)
> +{
> +   if (apple_gmux_present() && pdev != vga_default_device() &&
> +   !vgasr_priv.handler_flags)
> +   return true;
> +
> +   return false;
> +}
> +EXPORT_SYMBOL(vga_switcheroo_client_probe_defer);
> +




-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 10/12] drm/i915: Defer probe if gmux is present but its driver isn't

2016-02-14 Thread Lukas Wunner 
Hi,

On Tue, Feb 09, 2016 at 10:04:01AM +0100, Daniel Vetter wrote:
> On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote:
[...]
> > @@ -967,6 +970,15 @@ static int i915_pci_probe(struct pci_dev *pdev, const 
> > struct pci_device_id *ent)
> > if (PCI_FUNC(pdev->devfn))
> > return -ENODEV;
> >  
> > +   /*
> > +* apple-gmux is needed on dual GPU MacBook Pro
> > +* to probe the panel if we're the inactive GPU.
> > +*/
> > +   if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
> > +   apple_gmux_present() && pdev != vga_default_device() &&
> > +   !vga_switcheroo_handler_flags())
> > +   return -EPROBE_DEFER;
> 
> I pulled in all patches to drm-misc, but this here is imo ugly and needs
> to be polished a bit. What about adding a vga_switcheroo_ready() function
> which contains this check (and might in the future contain even more
> checks)? Then i915/radeon/nouveau would just have a simple
> 
>   if (!vga_switcheroo_ready())
>   return -EPROBE_DEFER;
> 
> and instead of duplicating the same comment 3 times we could have it once
> in one place. Plus some neat kerneldoc for this new helper to describe how
> it's supposed to be used. Plus better encapsulation of concepts.
> 
> Can you pls follow up with a patch/series to do that?

You're right, this is indeed much better. It also allows me to drop the
IS_ENABLED(CONFIG_VGA_ARB) and IS_ENABLED(CONFIG_VGA_SWITCHEROO) checks.

A patch follows below after the scissors.

The name vga_switcheroo_ready() was already taken by a static function
in vga_switcheroo.c, so I've named it vga_switcheroo_client_probe_defer().
If anyone has a suggestion for a better name I'll be happy to amend the
patch.

I've switched all three drivers to the new helper within the same patch
but will gladly spin this out into one patch per driver if preferred.

Thank you!

Lukas

-- >8 --
Subject: [PATCH] vga_switcheroo: Allow clients to determine whether to defer
 probing

So far we've got one condition when DRM drivers need to defer probing
on a dual GPU system and it's coded separately into each of the relevant
drivers. As suggested by Daniel Vetter, deduplicate that code in the
drivers and move it to a new vga_switcheroo helper. This yields better
encapsulation of concepts and lets us add further checks in a central
place. (The existing check pertains to pre-retina MacBook Pros and an
additional check is expected to be needed for retinas.)

Cc: Daniel Vetter 
Cc: Ben Skeggs 
Cc: Alex Deucher 
Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/i915/i915_drv.c   | 10 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c | 10 +-
 drivers/gpu/drm/radeon/radeon_drv.c   | 10 +-
 drivers/gpu/vga/vga_switcheroo.c  | 28 
 include/linux/vga_switcheroo.h|  2 ++
 5 files changed, 33 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 44912ec..80cfd73 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -35,11 +35,9 @@
 #include "i915_trace.h"
 #include "intel_drv.h"
 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -972,13 +970,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (PCI_FUNC(pdev->devfn))
return -ENODEV;
 
-   /*
-* apple-gmux is needed on dual GPU MacBook Pro
-* to probe the panel if we're the inactive GPU.
-*/
-   if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
-   apple_gmux_present() && pdev != vga_default_device() &&
-   !vga_switcheroo_handler_flags())
+   if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
 
return drm_get_pci_dev(pdev, ent, );
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index bb8498c..9141bcd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -22,13 +22,11 @@
  * Authors: Ben Skeggs
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "drmP.h"
@@ -314,13 +312,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
bool boot = false;
int ret;
 
-   /*
-* apple-gmux is needed on dual GPU MacBook Pro
-* to probe the panel if we're the inactive GPU.
-*/
-   if (IS_ENABLED(CONFIG_VGA_ARB) && IS_ENABLED(CONFIG_VGA_SWITCHEROO) &&
-   apple_gmux_present() && pdev != vga_default_device() &&
-   !vga_switcheroo_handler_flags())
+   if (vga_switcheroo_client_probe_defer(pdev))
return -EPROBE_DEFER;
 
/* remove conflicting drivers (vesafb, efifb etc) */
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c

[Intel-gfx] [PATCH i-g-t] Update MAINTAINERS file.

2016-02-14 Thread Marius Vlad 
Signed-off-by: Marius Vlad 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7825e1e..58f9efb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,2 +1,2 @@
 Daniel Vetter 
-Thomas Wood 
+Marius Vlad 
-- 
2.7.0

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