[Intel-gfx] [PATCH] drm/i915: Fix crash in auto_retire

[Stéphane Marchesin]

The retire logic uses the 2 lower bits of the pointer to the retire
function to store flags. However, the auto_retire function is not
guaranteed to be aligned to a multiple of 4, which causes crashes as
we jump to the wrong address, for example like this:

2021-04-24T18:03:53.804300Z WARNING kernel: [  516.876901] invalid opcode:  
[#1] PREEMPT SMP NOPTI
2021-04-24T18:03:53.804310Z WARNING kernel: [  516.876906] CPU: 7 PID: 146 
Comm: kworker/u16:6 Tainted: G U5.4.105-13595-g3cd84167b2df #1
2021-04-24T18:03:53.804311Z WARNING kernel: [  516.876907] Hardware name: 
Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021
2021-04-24T18:03:53.804312Z WARNING kernel: [  516.876911] Workqueue: 
events_unbound active_work
2021-04-24T18:03:53.804313Z WARNING kernel: [  516.876914] RIP: 
0010:auto_retire+0x1/0x20
2021-04-24T18:03:53.804314Z WARNING kernel: [  516.876916] Code: e8 01 f2 ff ff 
eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 
0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 
0f 88 9a 47 4a 00 74
2021-04-24T18:03:53.804319Z WARNING kernel: [  516.876918] RSP: 
0018:9b4d809fbe38 EFLAGS: 00010286
2021-04-24T18:03:53.804320Z WARNING kernel: [  516.876919] RAX: 
0007 RBX: 927915079600 RCX: 0007
2021-04-24T18:03:53.804320Z WARNING kernel: [  516.876921] RDX: 
9b4d809fbe40 RSI: 0286 RDI: 927915079600
2021-04-24T18:03:53.804321Z WARNING kernel: [  516.876922] RBP: 
9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff
2021-04-24T18:03:53.804321Z WARNING kernel: [  516.876924] R10: 
0010 R11: 92e44bd8 R12: 9279150796a0
2021-04-24T18:03:53.804322Z WARNING kernel: [  516.876925] R13: 
92791c368180 R14: 927915079640 R15: 1c867605
2021-04-24T18:03:53.804323Z WARNING kernel: [  516.876926] FS:  
() GS:92791ffc() knlGS:
2021-04-24T18:03:53.804323Z WARNING kernel: [  516.876928] CS:  0010 DS:  
ES:  CR0: 80050033
2021-04-24T18:03:53.804324Z WARNING kernel: [  516.876929] CR2: 
239514955000 CR3: 0007f82da001 CR4: 00760ee0
2021-04-24T18:03:53.804325Z WARNING kernel: [  516.876930] PKRU: 5554
2021-04-24T18:03:53.804325Z WARNING kernel: [  516.876931] Call Trace:
2021-04-24T18:03:53.804326Z WARNING kernel: [  516.876935]  
__active_retire+0x77/0xcf
2021-04-24T18:03:53.804326Z WARNING kernel: [  516.876939]  
process_one_work+0x1da/0x394
2021-04-24T18:03:53.804327Z WARNING kernel: [  516.876941]  
worker_thread+0x216/0x375
2021-04-24T18:03:53.804327Z WARNING kernel: [  516.876944]  kthread+0x147/0x156
2021-04-24T18:03:53.804335Z WARNING kernel: [  516.876946]  ? 
pr_cont_work+0x58/0x58
2021-04-24T18:03:53.804335Z WARNING kernel: [  516.876948]  ? 
kthread_blkcg+0x2e/0x2e
2021-04-24T18:03:53.804336Z WARNING kernel: [  516.876950]  
ret_from_fork+0x1f/0x40
2021-04-24T18:03:53.804336Z WARNING kernel: [  516.876952] Modules linked in: 
cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg 
xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw 
snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi 
snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common 
intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation 
soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda 
snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus 
snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core 
intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common 
videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 
v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse 
iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors 
cros_ec_sensors_core industrialio_triggered_buffer cros_ec_sensors_ring 
kfifo_buf industrialio cros_ec_sensorhub
2021-04-24T18:03:53.804337Z WARNING kernel: [  516.876972]  cdc_ether usbnet 
iwlmvm lzo_rle lzo_compress iwl7000_mac80211 iwlwifi zram cfg80211 r8152 mii 
btusb btrtl btintel btbcm bluetooth ecdh_generic ecc joydev
2021-04-24T18:03:53.804337Z EMERG kernel: [  516.879169] gsmi: Log Shutdown 
Reason 0x03

This change fixes this by aligning the function.

Signed-off-by: Stéphane Marchesin 
---
 drivers/gpu/drm/i915/i915_active.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c 
b/drivers/gpu/drm/i915/i915_active.c
index cf9a3d384971..aa573b078ae7 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -1156,7 +1156,8 @@ static int auto_active(struct i915_active *ref)
return 0;
 }
 
-static void auto_retire(struct i915_active *ref)
+__i915_active_call static void
+auto_retire(struct i915_active *ref)
 {
i915_active_put(ref);
 }
-- 
2.31.1.527.g47e6

Re: [Intel-gfx] [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver

[Stéphane Marchesin]

On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter  wrote:
>
> On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote:
> > Quoting Joonas Lahtinen (2019-01-15 16:47:27)
> > > Hi all,
> > >
> > > I would like to have some Acked-by's from you, the distro media
> > > folks Cc'd here, to document your intent to start using Intel's
> > > new media driver[1]. So if you recognize yourself (or are otherwise
> > > interested), please read on.
> > >
> > > TL;DR Distro folks, please give your Acked-by on patch [5/6]
> >
> > A gentle reminder, I'm still looking to hear back from Stephane
> > and Dave.
> >
> > We'd like to have this included in the final 5.1 drm-intel-next
> > pull request this week.
> >
> > If there are no further comments by Wed, I will conclude that we
> > have reached a silent agreement, and merge this to give enough
> > time for Rodrigo to send the PR.
>
> Maybe should add that ubunut/suse folks seem ok. Also, it's for libva, in
> the past that's been very far down the list of contentious topics. Mostly
> positive meh seems plenty good enough feedback I think.

FWIW I think the API changes are fine. Sure it feels a bit odd at
first, but there's no better alternative that I can see either.

Acked-by: Stéphane Marchesin 



> -Daniel
>
> >
> > Regards, Joonas
> >
> > > I believe most are already aware of the situation that Intel
> > > is moving to the new codebase for libva backend to support new Intel
> > > integrated graphics devices. The existing intel-libva-driver will
> > > be continue to be be supported for pre-Icelake platforms ( > > Icelake and further platforms will only be supported from the
> > > new codebase.
> > >
> > > There's the complication that some Icelake features of the new
> > > driver will require new kernel uAPIs to work... But the new driver
> > > has not yet been well-established in the community from perspective
> > > of fulfilling [2]. This is very much due to the demand being low
> > > as Icelake is not widely available yet. So it's bit of a chicken
> > > and egg problem as we have a new platform *and* a new codebase for
> > > it simultaneously.
> > >
> > > Ahead of that community adoption, to ensure that Icelake has good
> > > kernel support from day one, we'd like to merge kernel support for
> > > the parts that have functional effect (this series). This is to
> > > avoid the scenario where end users have to update their distro
> > > kernels, like happened with Skylake.
> > >
> > > So if I could get Acked-by's from distro folks on the patch [5/6] that
> > > adds the new uAPI. That would document their intent to become an active
> > > user of the media-driver[1]. If that happens in the next week or two,
> > > it would mean that Icelake hardware features would be supported in
> > > kernel version 5.1 fully from kernel driver point of view.
> > >
> > > The new uAPI is needed to make VME feature functionally work
> > > on Icelake. It's pretty much a simple enable/disable switch for
> > > hardware configuration that only includes hardware slices compatible
> > > with the VME workload. So it's currently limited to the required on/off
> > > choice to keep things straightforward. The uAPI can be extended in the
> > > future for possible performance gains for more fine-grained control.
> > >
> > > VME is shared function to handle motion estimation. One intended
> > > usercase is in Hierarchical Motion Estimation (HME) media kernel. It
> > > provides a bigger search range with reduced cost for the search. HME
> > > should improve the encode quality with scenarios where the video has
> > > a lot of motion in it. Carl (Cc'd) can provide more details if needed.
> > >
> > > The respective IGT tests are reviewed and can be found at:
> > >
> > >   https://patchwork.freedesktop.org/series/49190/
> > >
> > > The userspace changes are reviewed and rebased here:
> > >
> > >   https://github.com/intel/media-driver/pull/271
> > >   https://github.com/intel/media-driver/pull/463
> > >
> > > Best Regards, Joonas Lahtinen
> > >
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: Timo Aaltonen 
> > > Cc: Takashi Iwai 
> > > Cc: Stephane Marchesin 
> > > Cc: Dave Airlie 
> > > Cc: Daniel Vetter 
> > >
> > > PS. This series might result in some CI failures reported as it adds new 
> > > uA

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

On Thu, Dec 27, 2018 at 4:45 PM Matt Roper  wrote:
>
> On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C  wrote:
> > >
> > > Matt,
> > >
> > > Is that possible for you to get some time to review 
> > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > >  and confirm the FROMLIST change if it looks good to you so we could move 
> > > forward?
> > >
> >
> > To be more precise, I am trying to assess what's needed before this
> > patch goes usptream, and in particular, I'd like to know if we are
> > blocked on any Chrome-side thing.
> >
> > Stéphane
> >
>
> Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> from the ChromeOS userspace team on the ABI, plus a pointer to where the
> final, reviewed userspace patches are that correspond to it (mailing
> list link or gerrit or whatever).  I have an old gerrit link to some
> in-development chromium/ozone patches for this from November 2nd, but
> I'm not sure if there's a newer one now.

IMO from user space the ABI is good. I think the question is more
whether other hw would be fine with it. For example if we notice that
other platforms can only do black as a background color, how can we
make this API standard. Hopefully other folks can chime in here about
other hw capabilities.

Stéphane


>
> Aside from satisfying the ABI/userspace requirements, we still need all
> the patches to get reviewed by the upstream kernel devs.  An older
> version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> been accepted yet.  Actually it looks like I never sent the latest
> version of my series that incorporates some additional feedback from
> Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> people are still out on holiday vacation at the moment, so if necessary
> I'll start pinging IRC for reviews in a week or two when people are back
> in office.
>
>
> Matt
>
> >
> > > BTW, I've backported your kernel patch into Chrome OS and verified it 
> > > using the TEST=drm-tests/atomictest -t crtc_background_color on a Google 
> > > Pixelbook with KBL graphics.
> > >
> > > Thanks,
> > > Wei
> > >
> > > -Original Message-
> > > From: Stéphane Marchesin [mailto:marc...@chromium.org]
> > > Sent: Thursday, December 27, 2018 3:27 PM
> > > To: Roper, Matthew D 
> > > Cc: intel-gfx ; Li, Wei C 
> > > ; dri-devel 
> > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > >
> > > Hey,
> > >
> > > Is there anything missing on the Chrome side to move forward with this 
> > > series?
> > >
> > > Stéphane
> > >
> > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  
> > > wrote:
> > > >
> > > > Third version of the series previously posted here:
> > > >
> > > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > html
> > > >
> > > > This version incorporates review feedback from Ville and Sean Paul.
> > > >
> > > > The first patch here can be merged whenever it receives review approval.
> > > > The second and third patches still need to wait for opensource
> > > > userspace to be ready before merging (there's ChromeOS work underway).
> > > >
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Cc: Wei C Li 
> > > > Cc: Sean Paul 
> > > > Cc: Ville Syrjälä 
> > > >
> > > > Matt Roper (3):
> > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > >   drm: Add CRTC background color property (v2)
> > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > >
> > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > >  drivers/gpu/drm/drm_atomic_uapi.c |  5 
> > > >  drivers/gpu/drm/drm_blend.c   | 21 +---
> > > >  drivers/gpu/drm/drm_mode_config.c |  6 +
> > > >  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
> > > >  drivers/gpu/drm/i915/i915_reg.h   |  6 +
> > > >  drivers/gpu/drm/i915/intel_display.c  | 40 
> > > > +++
> > > >  include/drm/drm_blend.h   |  1 +
> > > >  include/drm/drm_crtc.h| 17 +
> > > >  include/drm/drm_mode_config.h |  5 
> > > >  include/uapi/drm/drm_mode.h   | 28 ++
> > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > >
> > > > --
> > > > 2.14.4
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > Intel-gfx@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C  wrote:
>
> Matt,
>
> Is that possible for you to get some time to review 
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
>  and confirm the FROMLIST change if it looks good to you so we could move 
> forward?
>

To be more precise, I am trying to assess what's needed before this
patch goes usptream, and in particular, I'd like to know if we are
blocked on any Chrome-side thing.

Stéphane


> BTW, I've backported your kernel patch into Chrome OS and verified it using 
> the TEST=drm-tests/atomictest -t crtc_background_color on a Google Pixelbook 
> with KBL graphics.
>
> Thanks,
> Wei
>
> -Original Message-
> From: Stéphane Marchesin [mailto:marc...@chromium.org]
> Sent: Thursday, December 27, 2018 3:27 PM
> To: Roper, Matthew D 
> Cc: intel-gfx ; Li, Wei C 
> ; dri-devel 
> Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
>
> Hey,
>
> Is there anything missing on the Chrome side to move forward with this series?
>
> Stéphane
>
> On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  wrote:
> >
> > Third version of the series previously posted here:
> >
> > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > html
> >
> > This version incorporates review feedback from Ville and Sean Paul.
> >
> > The first patch here can be merged whenever it receives review approval.
> > The second and third patches still need to wait for opensource
> > userspace to be ready before merging (there's ChromeOS work underway).
> >
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: Wei C Li 
> > Cc: Sean Paul 
> > Cc: Ville Syrjälä 
> >
> > Matt Roper (3):
> >   drm/i915: Force background color to black for gen9+ (v2)
> >   drm: Add CRTC background color property (v2)
> >   drm/i915/gen9+: Add support for pipe background color (v3)
> >
> >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >  drivers/gpu/drm/drm_atomic_uapi.c |  5 
> >  drivers/gpu/drm/drm_blend.c   | 21 +---
> >  drivers/gpu/drm/drm_mode_config.c |  6 +
> >  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
> >  drivers/gpu/drm/i915/i915_reg.h   |  6 +
> >  drivers/gpu/drm/i915/intel_display.c  | 40 
> > +++
> >  include/drm/drm_blend.h   |  1 +
> >  include/drm/drm_crtc.h| 17 +
> >  include/drm/drm_mode_config.h |  5 
> >  include/uapi/drm/drm_mode.h   | 28 ++
> >  11 files changed, 136 insertions(+), 3 deletions(-)
> >
> > --
> > 2.14.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

Hey,

Is there anything missing on the Chrome side to move forward with this series?

Stéphane

On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  wrote:
>
> Third version of the series previously posted here:
>   https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.html
>
> This version incorporates review feedback from Ville and Sean Paul.
>
> The first patch here can be merged whenever it receives review approval.
> The second and third patches still need to wait for opensource userspace
> to be ready before merging (there's ChromeOS work underway).
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Wei C Li 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
>
> Matt Roper (3):
>   drm/i915: Force background color to black for gen9+ (v2)
>   drm: Add CRTC background color property (v2)
>   drm/i915/gen9+: Add support for pipe background color (v3)
>
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c |  5 
>  drivers/gpu/drm/drm_blend.c   | 21 +---
>  drivers/gpu/drm/drm_mode_config.c |  6 +
>  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  6 +
>  drivers/gpu/drm/i915/intel_display.c  | 40 
> +++
>  include/drm/drm_blend.h   |  1 +
>  include/drm/drm_crtc.h| 17 +
>  include/drm/drm_mode_config.h |  5 
>  include/uapi/drm/drm_mode.h   | 28 ++
>  11 files changed, 136 insertions(+), 3 deletions(-)
>
> --
> 2.14.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v8 12/35] drm/i915: Implement the HDCP2.2 support for DP

[Stéphane Marchesin]

Hi,

Just a drive-by comment, but did you check that this fails gracefully
on platforms which don't enable the ME? For example Chrome OS :)

Stéphane

On Tue, Nov 27, 2018 at 2:48 AM Ramalingam C  wrote:
>
> Implements the DP adaptation specific HDCP2.2 functions.
>
> These functions perform the DPCD read and write for communicating the
> HDCP2.2 auth message back and forth.
>
> v2:
>   wait for cp_irq is merged with this patch. Rebased.
> v3:
>   wait_queue is used for wait for cp_irq [Chris Wilson]
> v4:
>   Style fixed.
>   %s/PARING/PAIRING
>   Few style fixes [Uma]
> v5:
>   Lookup table for DP HDCP2.2 msg details [Daniel].
>   Extra lines are removed.
> v6:
>   Rebased.
> v7:
>   Fixed some regression introduced at v5. [Ankit]
>   Macro HDCP_2_2_RX_CAPS_VERSION_VAL is reused [Uma]
>   Converted a function to inline [Uma]
>   %s/uintxx_t/uxx
> v8:
>   Error due to the sinks are reported as DEBUG logs.
>   Adjust to the new mei interface.
>
> Signed-off-by: Ramalingam C 
> Signed-off-by: Ankit K Nautiyal 
> Reviewed-by: Uma Shankar 
> ---
>  drivers/gpu/drm/i915/intel_dp.c   | 338 
> ++
>  drivers/gpu/drm/i915/intel_drv.h  |   7 +
>  drivers/gpu/drm/i915/intel_hdcp.c |   6 +
>  3 files changed, 351 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ecc4706db7dc..1cc82e490999 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -5347,6 +5348,27 @@ void intel_dp_encoder_suspend(struct intel_encoder 
> *intel_encoder)
> pps_unlock(intel_dp);
>  }
>
> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> +int timeout)
> +{
> +   long ret;
> +
> +   /* Reinit */
> +   atomic_set(>cp_irq_recved, 0);
> +
> +#define C (atomic_read(>cp_irq_recved) > 0)
> +   ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
> +  msecs_to_jiffies(timeout));
> +
> +   if (ret > 0) {
> +   atomic_set(>cp_irq_recved, 0);
> +   return 0;
> +   } else if (!ret) {
> +   return -ETIMEDOUT;
> +   }
> +   return (int)ret;
> +}
> +
>  static
>  int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
> u8 *an)
> @@ -5570,6 +5592,316 @@ int intel_dp_hdcp_capable(struct intel_digital_port 
> *intel_dig_port,
> return 0;
>  }
>
> +static struct hdcp2_dp_msg_data {
> +   u8 msg_id;
> +   u32 offset;
> +   bool msg_detectable;
> +   u32 timeout;
> +   u32 timeout2; /* Added for non_paired situation */
> +   } hdcp2_msg_data[] = {
> +   {HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
> +   {HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
> +   false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
> +   {HDCP_2_2_AKE_NO_STORED_KM, 
> DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
> +   false, 0, 0},
> +   {HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
> +   false, 0, 0},
> +   {HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
> +   true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
> +   HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
> +   {HDCP_2_2_AKE_SEND_PAIRING_INFO,
> +   DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, 
> true,
> +   HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
> +   {HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
> +   {HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
> +   false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
> +   {HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, 
> false,
> +   0, 0},
> +   {HDCP_2_2_REP_SEND_RECVID_LIST,
> +   DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
> +   HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
> +   {HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, 
> false,
> +   0, 0},
> +   {HDCP_2_2_REP_STREAM_MANAGE,
> +   DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
> +   0, 0},
> +   {HDCP_2_2_REP_STREAM_READY, 
> DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
> +   false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
> +   {HDCP_2_2_ERRATA_DP_STREAM_TYPE,
> +   DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
> +   0, 0},
> +   };
> +
> +static inline
> 

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Stéphane Marchesin]

On Fri, Aug 18, 2017 at 2:07 AM, Jani Nikula
<jani.nik...@linux.intel.com> wrote:
> On Thu, 17 Aug 2017, Stéphane Marchesin <marc...@chromium.org> wrote:
>> On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula
>> <jani.nik...@linux.intel.com> wrote:
>>>
>>> On Thu, 15 Jun 2017, Imre Deak <imre.d...@intel.com> wrote:
>>> > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
>>> >> I believe it is worth allowing RPM to work without requiring DMC, no?!
>>> >
>>> > Not if there is no good reason for not using DMC. It was decided early
>>> > on that we won't support that configuration since if you care about the
>>> > power saving provided by partially disabling things you probably also
>>> > care about the bigger power saving provided by DMC. So that is the
>>> > current state of the driver, enabling runtime PM without having DMC
>>> > loaded is not supported. Proper support for that would need to be added
>>> > after a justification why not to use the firmware.
>>>
>>> Agreed. We already have too many configurations to support, and we
>>> already struggle with our testing coverage as-is. Adding new
>>> configurations to be tested is not to be taken lightly.
>>>
>>
>> For context, we are seeing GPU hangs at suspend/resume with DMC
>> enabled (feel free to email me if you want to be added to the internal
>> bug) which is the reason for this patch. If those GPU hangs can be
>> fixed instead, then that would be an even better solution, IMO. Is
>> there someone on your side who could help with these hangs?
>
> We need to get the GPU hangs fixed, obviously. Is this reproducible with
> upstream code? Do we have a bug about this at bugs.freedesktop.org?
> Jani, Jari?
>

I am CCing intel people who were looking into this bug, and who
suggested to disable DMC as a solution. You can probably talk to them
directly :)

Stéphane


> BR,
> Jani.
>
>
>>
>> Stéphane
>>
>>>
>>> BR,
>>> Jani.
>>>
>>> --
>>> Jani Nikula, Intel Open Source Technology Center
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Stéphane Marchesin]

On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula
 wrote:
>
> On Thu, 15 Jun 2017, Imre Deak  wrote:
> > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
> >> I believe it is worth allowing RPM to work without requiring DMC, no?!
> >
> > Not if there is no good reason for not using DMC. It was decided early
> > on that we won't support that configuration since if you care about the
> > power saving provided by partially disabling things you probably also
> > care about the bigger power saving provided by DMC. So that is the
> > current state of the driver, enabling runtime PM without having DMC
> > loaded is not supported. Proper support for that would need to be added
> > after a justification why not to use the firmware.
>
> Agreed. We already have too many configurations to support, and we
> already struggle with our testing coverage as-is. Adding new
> configurations to be tested is not to be taken lightly.
>

For context, we are seeing GPU hangs at suspend/resume with DMC
enabled (feel free to email me if you want to be added to the internal
bug) which is the reason for this patch. If those GPU hangs can be
fixed instead, then that would be an even better solution, IMO. Is
there someone on your side who could help with these hangs?

Stéphane

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

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Stéphane Marchesin]

On Thu, Jul 13, 2017 at 10:42 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Thu, Jul 13, 2017 at 09:23:11AM -0700, Stéphane Marchesin wrote:
>> On Thu, Jul 13, 2017 at 3:13 AM, Ville Syrjälä
>> <ville.syrj...@linux.intel.com> wrote:
>> > On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote:
>> >> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
>> >> <ville.syrj...@linux.intel.com> wrote:
>> >> >
>> >> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> >> > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>> >> > >
>> >> > > > In several instances the driver passes an 'enum pipe' value to a
>> >> > > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x 
>> >> > > > and
>> >> > > > TRANSCODER_x have the same values this doesn't cause functional
>> >> > > > problems. Still it is incorrect and causes clang to generate 
>> >> > > > warnings
>> >> > > > like this:
>> >> > > >
>> >> > > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
>> >> > > >   conversion from enumeration type 'enum transcoder' to different
>> >> > > >   enumeration type 'enum pipe' [-Wenum-conversion]
>> >> > > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
>> >> > > >
>> >> > > > Change the code to pass values of the type expected by the callee.
>> >> > > >
>> >> > > > Signed-off-by: Matthias Kaehlcke <m...@chromium.org>
>> >> > > > ---
>> >> > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>> >> > > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
>> >> > > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
>> >> > > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
>> >> > > >  4 files changed, 14 insertions(+), 8 deletions(-)
>> >> > >
>> >> > > Ping, any comments on this patch?
>> >> >
>> >> > I'm not convinced the patch is making things any better really. To
>> >> > fix this really properly, I think we'd need to introduce a new enum
>> >> > pch_transcoder and thus avoid the confusion of which type of
>> >> > transcoder we're talking about. Currently most places expect an
>> >> > enum pipe when dealing with PCH transcoders, and enum transcoder
>> >> > when dealing with CPU transcoders. But there are some exceptions
>> >> > of course.
>> >>
>> >>
>> >> I don't follow -- these functions take an enum transcoder; what's
>> >> wrong about passing what they expect? It seems like what you are
>> >> asking for has nothing to do with the warning here...
>> >
>> > There's a warning? I don't get any.
>>
>> Yup, clang generates a warning.
>>
>> >
>> > Anyways, I just don't see much point in blindly changing the types
>> > because it doesn't actually solve the underlying confusion for human
>> > readers. It might even make it worse, not sure.
>>
>> The function expects type A, you pass type B, how can that ever be the
>> right thing to do?
>
> Because maybe the function should be taking in type B instead.

So, if you think this is wrong, can you fix this warning in a way that
you'd like?

Stéphane

>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Stéphane Marchesin]

On Thu, Jul 13, 2017 at 3:13 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Wed, Jul 12, 2017 at 07:28:14PM -0700, Stéphane Marchesin wrote:
>> On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
>> <ville.syrj...@linux.intel.com> wrote:
>> >
>> > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
>> > > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
>> > >
>> > > > In several instances the driver passes an 'enum pipe' value to a
>> > > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
>> > > > TRANSCODER_x have the same values this doesn't cause functional
>> > > > problems. Still it is incorrect and causes clang to generate warnings
>> > > > like this:
>> > > >
>> > > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
>> > > >   conversion from enumeration type 'enum transcoder' to different
>> > > >   enumeration type 'enum pipe' [-Wenum-conversion]
>> > > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
>> > > >
>> > > > Change the code to pass values of the type expected by the callee.
>> > > >
>> > > > Signed-off-by: Matthias Kaehlcke <m...@chromium.org>
>> > > > ---
>> > > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>> > > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
>> > > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
>> > > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
>> > > >  4 files changed, 14 insertions(+), 8 deletions(-)
>> > >
>> > > Ping, any comments on this patch?
>> >
>> > I'm not convinced the patch is making things any better really. To
>> > fix this really properly, I think we'd need to introduce a new enum
>> > pch_transcoder and thus avoid the confusion of which type of
>> > transcoder we're talking about. Currently most places expect an
>> > enum pipe when dealing with PCH transcoders, and enum transcoder
>> > when dealing with CPU transcoders. But there are some exceptions
>> > of course.
>>
>>
>> I don't follow -- these functions take an enum transcoder; what's
>> wrong about passing what they expect? It seems like what you are
>> asking for has nothing to do with the warning here...
>
> There's a warning? I don't get any.

Yup, clang generates a warning.

>
> Anyways, I just don't see much point in blindly changing the types
> because it doesn't actually solve the underlying confusion for human
> readers. It might even make it worse, not sure.

The function expects type A, you pass type B, how can that ever be the
right thing to do?

Stéphane


>
> --
> 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] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

[Stéphane Marchesin]

On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä
 wrote:
>
> On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote:
> > El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit:
> >
> > > In several instances the driver passes an 'enum pipe' value to a
> > > function expecting an 'enum transcoder' and viceversa. Since PIPE_x and
> > > TRANSCODER_x have the same values this doesn't cause functional
> > > problems. Still it is incorrect and causes clang to generate warnings
> > > like this:
> > >
> > > drivers/gpu/drm/i915/intel_display.c:1844:34: warning: implicit
> > >   conversion from enumeration type 'enum transcoder' to different
> > >   enumeration type 'enum pipe' [-Wenum-conversion]
> > > assert_fdi_rx_enabled(dev_priv, TRANSCODER_A);
> > >
> > > Change the code to pass values of the type expected by the callee.
> > >
> > > Signed-off-by: Matthias Kaehlcke 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > >  drivers/gpu/drm/i915/intel_dp.c  | 6 --
> > >  drivers/gpu/drm/i915/intel_hdmi.c| 6 --
> > >  drivers/gpu/drm/i915/intel_sdvo.c| 6 --
> > >  4 files changed, 14 insertions(+), 8 deletions(-)
> >
> > Ping, any comments on this patch?
>
> I'm not convinced the patch is making things any better really. To
> fix this really properly, I think we'd need to introduce a new enum
> pch_transcoder and thus avoid the confusion of which type of
> transcoder we're talking about. Currently most places expect an
> enum pipe when dealing with PCH transcoders, and enum transcoder
> when dealing with CPU transcoders. But there are some exceptions
> of course.


I don't follow -- these functions take an enum transcoder; what's
wrong about passing what they expect? It seems like what you are
asking for has nothing to do with the warning here...

Stéphane

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Stéphane Marchesin]

On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
benjamin.tissoi...@redhat.com wrote:
 On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:


 On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
 On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
 why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you 
 can
 identify both lane count and reversal state without touching anything in 
 the
 link training code. i am yet to upstream my changes for CHT that i can 
 share
 if required that does the same in intel_dp_detect without touching any line
 in link training path.
 With my current limited knowledge of the dp hotplug (and i915 driver) I
 am not sure we could detect the reversed state without trying to train 1
 lane only. I'd be glad to look at your changes and test them on my
 system if you think that could help having a cleaner solution.
 
 Cheers,
 Benjamin
 No, what i recommended was to do link training but in intel_dp_detect. Since
 USB Type C cable
 also has its own lane count restriction (it can have different lane count
 than the one supported
 by panel) you might have to figure that out as well. so both reversal and
 lane count detection
 can be done outside the modeset path and keep the code free of type C
 changes outside
 detection path.

 Please find below the code to do the same. Do not waste time trying to apply
 this directly on
 nightly since this is based on a local tree and because this is pre- atomic
 changes code, so you
 might have to modify chv_upfront_link_train to work on top of the latest
 nightly code. we
 are supposed to upstream this and is in my todo list.


 [original patch snipped...]

 Hi Sivakumar,

 So I managed to manually re-apply your patch on top of
 drm-intel-nightly, and tried to port it to make Broadwell working too.
 It works OK if the system is already boot without any external DP used.
 In this case, the detection works and I can see my external monitor
 working properly.

 However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
 understand why. I think I enabled all that is mentioned in the PRM to be
 able to train the DP link, but I am obviously missing something else.
 Can you have a look?


Hi Benjamin,

I would recommend against this approach. Some adapters will claim that
they recovered a clock even when it isn't on the lanes you enabled,
which means that the reversal detection doesn't always work. The only
reliable way to do this is to go talk to the Chrome OS EC (you can
find these patches later in the Chrome OS tree). It's not as generic,
but we might be able to abstract that logic, maybe.

Stéphane



 My patch is now:

 From 11e9c42f55ae27bd6e7b0168bf24d15082c7d517 Mon Sep 17 00:00:00 2001
 From: Durgadoss R durgados...@intel.com
 Date: Mon, 3 Aug 2015 11:51:16 -0400
 Subject: [PATCH] drm/i915: Enable Upfront link training for type-C DP support

 To support USB type C alternate DP mode, the display driver needs to know the
 number of lanes required by 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 the link
 training fails, the driver then falls back to x2 lanes.

 * Since link training is done before modeset, planes are not enabled. Only
   encoder and the its associated PLLs are enabled.
 * Once link training is done, the encoder and its PLLs are disabled; so that
   the subsequent modeset is not aware of these changes.
 * As of now, this is tested only on CHV.

 Signed-off-by: Durgadoss R durgados...@intel.com
 [BT: add broadwell support and USB-C reverted state detection]
 Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
 ---
  drivers/gpu/drm/i915/intel_display.c | 163 
 +++
  drivers/gpu/drm/i915/intel_dp.c  |  22 -
  drivers/gpu/drm/i915/intel_drv.h |   7 ++
  3 files changed, 190 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 818f3a3..e8ddba0 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -15799,3 +15799,166 @@ void intel_modeset_preclose(struct drm_device *dev, 
 struct drm_file *file)
 spin_unlock_irq(dev-event_lock);
 }
  }
 +
 +static bool
 +intel_upfront_link_train_config(struct drm_device *dev,
 +   struct intel_dp *intel_dp,
 +   struct intel_crtc *crtc,
 +   uint8_t link_bw,
 +   uint8_t lane_count)
 +{
 +   struct drm_i915_private *dev_priv = dev-dev_private;
 +   struct intel_connector *connector = intel_dp-attached_connector;
 +   struct intel_encoder *encoder = connector-encoder;
 +   bool success;
 +
 +   intel_dp-link_bw = 

Re: [Intel-gfx] eDP display control registers in Linux kernel

[Stéphane Marchesin]

On Sun, Feb 22, 2015 at 11:59 PM, Jani Nikula jani.nik...@intel.com wrote:

 Hi Michael -

 Please always cc: the relevant mailing lists; done now.

 On Sun, 22 Feb 2015, Michael Leuchtenburg mich...@slashhome.org wrote:
 Hi Jani,

 I've been trying to figure out how to control the dynamic backlight control
 on my new Dell XPS 13 since the defaults are atrocious - huge swings in
 brightness from a black background to a white one, over a few seconds
 period so it's very obvious. I eventually tracked down a patch from the
 Chromium folks that adds a sysfs interface (
 https://chromium.googlesource.com/chromiumos/third_party/kernel/+/db5eacd6ac7a0cbda4ea1010fabbd3ff6b30e0bc%5E%21/),
 but it seems to depend on your patch that adds eDP display control
 registers (
 http://lists.freedesktop.org/archives/dri-devel/2013-November/049098.html),
 which was never merged into mainline as far as I can tell.

 Do you know what the status of that is? Is it still wending its way through
 the process (now, over a year later) or did it die somewhere along the way?
 The patch doesn't apply to mainline today, though it's simple enough that I
 suspect it'd be easy to adapt. I'd rather see where it went, though.

 I'd appreciate any help you can offer.

 The Chrome OS patches wouldn't be acceptable upstream, and indeed
 they've never been posted upstream. A more driver agnostic approach
 would be required.

I actually asked Eric to make a property version of this:
https://chromium-review.googlesource.com/#/c/244165/

Once this lands in Chrome OS, we should upstream it.

Stéphane


 My patches were simple, adding some macros etc. They were reviewed but
 apparently forgotten, also by me. I'll repost them, but they won't do
 you much good in this case.

 I'm also not convinced yet that your problem would be solved by the
 patches; are you sure Dell XPS 13 does have dynamic backlight control in
 the panel, adjustable via DPCD?

 BR,
 Jani.


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

Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace

[Stéphane Marchesin]

On Tue, Nov 18, 2014 at 3:18 PM, Eoff, Ullysses A
ullysses.a.e...@intel.com wrote:
 Thanks Jesse for the ack.

 Unfortunately I just learned from Stéphane that there
 are certain devices which only support 256 levels, so this
 patch would do us no good at solving the real issue for
 such devices.

 Why can't we just use a dynamic 1:1 mapping as was
 suggested before?  I would vote for that instead.


Right, from my (consumer's) perspective, a 1:1 mapping is simpler. But
the confusing part for me is that (as far as I can see) the current
mapping should be 1:1 (because the user and hw ranges are the same),
even though it goes through the scale logic. Is the scale() function
maybe not the identity? If it isn't, maybe we just need to make it
so...

Stéphane


 
 U. Artie

 -Original Message-
 From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
 Sent: Tuesday, November 18, 2014 9:23 AM
 To: Eoff, Ullysses A
 Cc: intel-gfx@lists.freedesktop.org; Jani Nikula
 Subject: Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range 
 to userspace

 On Tue, 11 Nov 2014 12:30:38 -0800
 U. Artie Eoff ullysses.a.e...@intel.com wrote:

  A userspace brightness range that is larger than the hardware
  brightness range does not have a 1:1 mapping and can result
  in brightness != actual_brightness for some values.
 
  Expose a fixed brightness range of [0..1000] to userspace so
  that all values can map 1:1 into the hardware brightness
  range.  This would assume that the hardware range is always
  greater than 1000, otherwise we're right back to the original
  issue.
 
  This patch is based on Jani Nikula's proposed change in the
  referenced ML thread, except use the range [0..1000] instead;
  which was recommended by Jesse Barnes for smoother backlight
  transitions.
 
  Reference: 
  http://lists.freedesktop.org/archives/intel-gfx/2014-November/055221.html
  Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com
  ---
   drivers/gpu/drm/i915/intel_panel.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_panel.c 
  b/drivers/gpu/drm/i915/intel_panel.c
  index 4d63839..f74f5f2 100644
  --- a/drivers/gpu/drm/i915/intel_panel.c
  +++ b/drivers/gpu/drm/i915/intel_panel.c
  @@ -1057,7 +1057,7 @@ static int intel_backlight_device_register(struct 
  intel_connector *connector)
   * Note: Everything should work even if the backlight device max
   * presented to the userspace is arbitrarily chosen.
   */
  -   props.max_brightness = panel-backlight.max;
  +   props.max_brightness = 1000;
  props.brightness = scale_hw_to_user(connector,
  panel-backlight.level,
  props.max_brightness);

 Yeah looks ok to me.  I guess Jani has to ack it too.

 Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org

 --
 Jesse Barnes, 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] [RFC] dpms handling on atomic drivers

[Stéphane Marchesin]

On Thu, Nov 6, 2014 at 1:43 AM, Daniel Vetter dan...@ffwll.ch wrote:

 Hi all,

 After a few atomic irc chats I've shockingly realized that I've completely
 ignored dpms handling in my helper series. Oops.

 But there's a few things which are seriously wrong with DPMS, so I've
 figured I'll start a discussion about them first - converting to atomic
 looks like a good time to fix up past mistakes, simplify drivers and make
 the interface exposed to userspace more consistent.

 1. Intermediate dpms levels

 DPMS standby/suspend essentially ceased to be useful years ago: Intel
 doesn't ship hardware which supports them since a few years, and analog
 CRTs (the only thing that cares really) are also dying. And these
 intermediate levels cause quite a bit of pain in drivers since depending
 upon the level and chip/output the pipe needs to be shut off or kept
 running, but with black output. That means more possible state transitions
 and invariable more bugs.

 Proposal: Just clamp dpms standy/suspend to off in the atomic
 implementation of dpms.


One thing that has been discussed in the past is how to send hdmi
audio while in dpms off state. On some platforms we've been abusing
these extra dpms levels. Overall it would be useful to have a way to
do that.




 2. Cloned configurations

 Currently dpms is set per-connector, and the crtc helpers only shut down
 the specific encoder. Only when all connectors are off will it shut down
 the crtc, too. That pretty much defeats the point of the new helpers of
 always enabling/disabling a given output pipeline holesale and in the same
 order. i915 modeset tries to have the cake and eat it with some clever
 bit-frobbing on the encoder (to select black output when needed) but
 otherwise only enable/disable the entire pipe. Imo that was stupid and not
 worth the complexity at all, furthermore it needs changes in all drivers
 to implement. Especially since X doesn't care about per-connector dpms.
 And even for multi-seat dpms will switch only per-crtc.

 Proposal: Only shut down anything (and then the hole output pipe with all
 cloned outputs) when all connector's dpms property is set to off. And
 enable it again as soon as one property goes to on.

 3. No internal representation of dpms state

 Because of the above nonsense it's essentially not possible to find out in
 a generic way whether the crtc is actually on. Which means that no generic
 (core or helper code) can figure out whether e.g. vblanks still happen.
 In the atomic helpers I just do a drm_vblank_get and look at the return
 value to figure out whether the crtc is on or not. This is one giant mess.

 Proposal. Add a new boolean -active to the crtc state, which will track
 the dpms state of the crtc. Add a helper to the atomic core functions
 which will compute -active from the state update according to the
 proposals for issue 12. Require that all callers of
 -atomich_check/commit update -active properly and require
 implementations to obey it. That means the atomic helpers will switch from
 looking at -enable to looking at -active to decided whether a crtc an
 all its outputs should be enabled or not.


That pretty much means completely automated crtc enable/disable in the
drm core then? That sounds great, but we should be careful with
drivers relying on vblank interrupts coming in (for example waiting
for vblank during modeset would fail if the crtc is disabled). I guess
if that's an issue you can work around it on the driver side.

Another thing which could potentially break is that X tracks (and
caches) the crtc dpms state.



 4. Modesets always force dpms on

 This is essentially a side-effect of how the crtc helpers have been
 implemented. Except that for a very long time the sw side tracking wasnt
 ever updated, resulting in lots of hilarity in all the drivers that
 checked the dpms state somewhere and got confused. Or userspace which also
 somehow believed the dpms state has any match with reality.

 Proposal: Enforce the informal rule that after a legacy -set_config call
 all connectors should be in dpms on. We should probably do this in the drm
 core right after having called -set_config to catch all possible
 implementations. For the actual atomic interface the solution for issue 3.
 will allow us to separate these two things and userspace to always know
 what's going on.


+1, that's making the de facto standard explicit.



 5. Inconsistent return values for vblank waits/page flips

 Becuase of issues 1-3 the core can't reject vblank waits or async page
 flips. Which means there's no consistency at all about when such an ioctl
 will work and when it will be rejected (because the pipe is off).

 Proposal: Use the new -active state from issue 3 and implement in the
 core what i915 currently does. Which means reject vblank waits and page
 flip ioctls when -active == false.

 For the atomic interface I think we should reject it if userspace asks for
 an event or async commit and neither the old nor 

Re: [Intel-gfx] [RFC PATCH 0/3] drm driver for baytrail's vxd392

[Stéphane Marchesin]

On Wed, Oct 15, 2014 at 1:13 AM, Thierry Reding thierry.red...@gmail.com
wrote:

 On Tue, Oct 14, 2014 at 08:50:35AM -0700, Sean V Kelley wrote:
  On Tue, Oct 14, 2014 at 4:53 AM, Thierry Reding
  thierry.red...@gmail.com wrote:
   On Mon, Oct 13, 2014 at 08:15:00PM +0800, Yao Cheng wrote:
   drm/ipvr is a new GEM driver for baytrail's vxd392, which accelerates
 VP8 video decoding.
   The driver name ipvr means the PowerVR's IP wrapped by Intel. In
 the future, ipvr may support other platforms such as Merrifield.
   Code is placed at drivers/gpu/drm/ipvr and the following two new
 Kconfig are added:
 CONFIG_DRM_IPVR: Build option for ipvr module
 CONFIG_DRM_IPVR_EC: Experimental feature of error concealment
  
   User mode drm helper libdrm_ipvr.so and simple test are also
 included.
  
   Yao Cheng (3):
[1/3] drm/i915: add vxd392 bridge in i915 on baytrail
[2/3] drm/ipvr: ipvr drm driver for vxd392
  
   If this is Intel-specific, why doesn't it live under the i915 driver?
 
  It is an entirely unrelated HW IP block, VXD392.  Nothing to do with
  GEN aside from DRM based.

 With GEN you're referring to the Intel integrated GPU? And VXD392 I take
 it is the IP block licensed by Imagination? Baytrail and others then
 wrap some additional logic around this as it is integrated into the SoC?

 How much wrapping actually happens here? I worry that this is going to
 lead to a lot of duplication if we ever want to support another SoC that
 uses the VXD392 IP. Could the code be split into a VXD392 library and
 some driver that implements the Intel-specific glue?

 Finally, if this IP block is a VP8 video decoding engine only, I'm not
 sure DRM is the best subsystem for it. Traditionally video decoding has
 been done primarily in V4L2. I'm not sure that's the best fit given that
 it was originally designed for video capturing, but they've evolved some
 infrastructure to deal with encoding/decoding, whereas we have nothing
 like that at all in DRM.


That isn't true. i915, nouveau and radeon drm drivers all support video
decoding user space in some form.

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: enable fastboot by default

[Stéphane Marchesin]

On Tue, Jun 10, 2014 at 10:31 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Tue, 10 Jun 2014 16:07:44 +0200
 Daniel Vetter dan...@ffwll.ch wrote:

 On Thu, Jun 05, 2014 at 11:24:31AM -0700, Jesse Barnes wrote:
  Let them eat mincemeat pie.
 
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   drivers/gpu/drm/i915/i915_params.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/i915_params.c 
  b/drivers/gpu/drm/i915/i915_params.c
  index d05a2af..081ab2f 100644
  --- a/drivers/gpu/drm/i915/i915_params.c
  +++ b/drivers/gpu/drm/i915/i915_params.c
  @@ -41,7 +41,7 @@ struct i915_params i915 __read_mostly = {
  .preliminary_hw_support = 
  IS_ENABLED(CONFIG_DRM_I915_PRELIMINARY_HW_SUPPORT),
  .disable_power_well = 1,
  .enable_ips = 1,
  -   .fastboot = 0,
  +   .fastboot = 42,
  .prefault_disable = 0,
  .reset = true,
  .invert_brightness = 0,
  @@ -132,7 +132,7 @@ MODULE_PARM_DESC(enable_ips, Enable IPS (default: 
  true));
 
   module_param_named(fastboot, i915.fastboot, bool, 0600);
   MODULE_PARM_DESC(fastboot,
  -   Try to skip unnecessary mode sets at boot time (default: false));
  +   Try to skip unnecessary mode sets at boot time (default: true));

 Nah, that wasn't the intention of this option. It was meant as a hack to
 experiment around with fastboot and get things going, but imo we need to
 really do the full modeset and short-circuit if the state matches.

 And there's still a bunch of things we don't track like infoframes which
 we either need to fix up (similar to the pfit fixup) or quirk to disallow
 fastboot.

 Hm that contradicts our earlier discussions w/Damien when we decided
 the infoframes stuff were too esoteric to matter...

My 2 cents is that I've seen some really bad TVs which didn't work
because infoframes were missing (IIRC it relied on the VIC to detect
the video mode).

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

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

[Stéphane Marchesin]

On Wed, Jun 4, 2014 at 2:11 AM, Jani Nikula jani.nik...@intel.com wrote:
 On Wed, 04 Jun 2014, Stéphane Marchesin marc...@chromium.org wrote:
 On Tue, Jun 3, 2014 at 1:26 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Jun 3, 2014 at 6:40 PM, Stéphane Marchesin marc...@chromium.org 
 wrote:
 On Tue, Apr 29, 2014 at 1:30 PM, Jani Nikula jani.nik...@intel.com wrote:
 Historically we've exposed the full backlight PWM duty cycle range to
 the userspace, in the name of mechanism, not policy. However, it turns
 out there are both panels and board designs where there is a minimum
 duty cycle that is required for proper operation. The minimum duty cycle
 is available in the VBT.

 The backlight class sysfs interface does not make any promises to the
 userspace about the physical meaning of the range
 0..max_brightness. Specifically there is no guarantee that 0 means off;
 indeed for acpi_backlight 0 usually is not off, but the minimum
 acceptable value.

 This is the part we've been relying on in Chrome OS (we assume that 0
 means off). It seems to me that i915 would be the first, or one of the
 first drivers to violate this rule (in particular you can find a lot
 of backlight drivers trying hard to ensure that 0 means off in the
 backlight drivers directory).

 For context, we use backlight = 0 as a quick turn the panel off
 function where possible. This allows us to avoid the panel off delay
 where possible. Breaking this assumption means that we'd pay the panel
 off delay penalty everywhere, not just with BYT.

 Well kde is the opposite and I've had users yelling at me that they
 can't use their system, since acpi pretty much always leaves the
 backlight on when set to 0. And acpi kinda rules on intel platforms.
 So I think I'll merge this one since black screens trumps a slight
 functional degration and we didn't duct-tape over the kde assumptions
 either. Essentially you can't assume anything about backlight values
 besides that bigger values tends to mean brigther. Linearity, absolute
 values and endpoints are kinda all off.

 It seems fairly wrong to model the backlight behavior after the only
 thing everyone agrees is broken (ACPI).

 Please don't put words into everyone's mouth.

 Talking to folks on IRC, Dave Airlie said, I think its been disagreed
 over the years to be implementation dependent. and Matthew Garrett
 said, It's currently implementation dependent. It can never mean off
 under all circumstances (not all interfaces offer a way to turn it
 off).

 I don't know whether they think ACPI is broken, but clearly there's no
 one true answer, and I think it's not the correct approach for userspace
 to assume 0 means off.

Well, for example ACPI backlight isn't the default on intel, instead
i915 implements its own backlight. ACPI backlight doesn't support as
many backlight levels as the native backlight for example. So I do
think that ACPI backlight is inferior.


 If you go through the backlight drivers, (at least all the ones I've
 looked at) ensure that 0 really means off.

 And systemd goes out of it's way to not switch backlight off on those
 interfaces... and it's obvious they can't assume anything about the
 meaning of 0 either:

 http://cgit.freedesktop.org/systemd/systemd/commit/?id=7b909d7407965c03caaba30daae7aee113627a83

This seems unrelated, they just turn the backlight to non-zero to make
things visible?


 If we want to specifically expose an intermediate panel off level
 because the full link training is too expensive we imo should do this
 as an intermediate dpms level, e.g. dpms standby.

 Training isn't the problem, the panel delays are the problem here (and
 not something we can work around because it's part of the panel
 specifications which we have to follow). Using dpms wouldn't solve
 anything.

 We could have dpms standby mean backlight off, everything else on,
 similarly to what you want by 0 backlight meaning off. So you could
 switch between dpms on/standby more quickly. The point in that is that
 it's the right API for doing panel power sequencing.

 You see, even with defining backlight 0 = off, we'd have to respect the
 panel sequencing and delays for backlight (admittedly we currently don't
 do that, which is why it's fast - and broken).

There are multiple delays at play here, and typically the longest
panel delays have nothing to do with the backlight but they are the
delays for turning the panel on/off (usually the panel on/off delays
are much bigger, up to 500ms on some panels). These are the delays I'm
trying to avoid.

 Doing the panel
 sequencing properly from the backlight interface gets *much* harder
 because it's all backwards in the stack then.

If you implement some interface which does set backlight to 0 on
platforms which support it, and do panel off on other platforms,
that's fine by me; however I don't want to regress all the other
platforms just because BYT has issues. In the current state of things,
the functionality set which is made available

Re: [Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

[Stéphane Marchesin]

On Tue, Apr 29, 2014 at 1:30 PM, Jani Nikula jani.nik...@intel.com wrote:
 Historically we've exposed the full backlight PWM duty cycle range to
 the userspace, in the name of mechanism, not policy. However, it turns
 out there are both panels and board designs where there is a minimum
 duty cycle that is required for proper operation. The minimum duty cycle
 is available in the VBT.

 The backlight class sysfs interface does not make any promises to the
 userspace about the physical meaning of the range
 0..max_brightness. Specifically there is no guarantee that 0 means off;
 indeed for acpi_backlight 0 usually is not off, but the minimum
 acceptable value.

This is the part we've been relying on in Chrome OS (we assume that 0
means off). It seems to me that i915 would be the first, or one of the
first drivers to violate this rule (in particular you can find a lot
of backlight drivers trying hard to ensure that 0 means off in the
backlight drivers directory).

For context, we use backlight = 0 as a quick turn the panel off
function where possible. This allows us to avoid the panel off delay
where possible. Breaking this assumption means that we'd pay the panel
off delay penalty everywhere, not just with BYT.

Stéphane


 Respect the minimum backlight, and expose the range acceptable to the
 hardware as 0..max_brightness to the userspace via the backlight class
 device; 0 means the minimum acceptable enabled value. To switch off the
 backlight, the user must disable the encoder.

 As a side effect, make the backlight class device max brightness and
 physical PWM modulation frequency (i.e. max duty cycle) independent.

 Signed-off-by: Jani Nikula jani.nik...@intel.com

 ---

 UNTESTED!
 ---
  drivers/gpu/drm/i915/i915_drv.h|  1 +
  drivers/gpu/drm/i915/intel_bios.c  |  3 +-
  drivers/gpu/drm/i915/intel_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_panel.c | 97 
 +++---
  4 files changed, 85 insertions(+), 17 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 50dfc3a1a9d1..d9dad3498b87 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1164,6 +1164,7 @@ struct intel_vbt_data {
 u16 pwm_freq_hz;
 bool present;
 bool active_low_pwm;
 +   u8 min_brightness;  /* min_brightness/255 of max */
 } backlight;

 /* MIPI DSI */
 diff --git a/drivers/gpu/drm/i915/intel_bios.c 
 b/drivers/gpu/drm/i915/intel_bios.c
 index 2945f57c53ee..1a3e172029b3 100644
 --- a/drivers/gpu/drm/i915/intel_bios.c
 +++ b/drivers/gpu/drm/i915/intel_bios.c
 @@ -339,11 +339,12 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv, 
 struct bdb_header *bdb)

 dev_priv-vbt.backlight.pwm_freq_hz = entry-pwm_freq_hz;
 dev_priv-vbt.backlight.active_low_pwm = entry-active_low_pwm;
 +   dev_priv-vbt.backlight.min_brightness = entry-min_brightness;
 DRM_DEBUG_KMS(VBT backlight PWM modulation frequency %u Hz, 
   active %s, min brightness %u, level %u\n,
   dev_priv-vbt.backlight.pwm_freq_hz,
   dev_priv-vbt.backlight.active_low_pwm ? low : high,
 - entry-min_brightness,
 + dev_priv-vbt.backlight.min_brightness,
   backlight_data-level[panel_type]);
  }

 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index d8b540b891d1..2af74dd03e31 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -165,6 +165,7 @@ struct intel_panel {
 struct {
 bool present;
 u32 level;
 +   u32 min;
 u32 max;
 bool enabled;
 bool combination_mode;  /* gen 2/4 only */
 diff --git a/drivers/gpu/drm/i915/intel_panel.c 
 b/drivers/gpu/drm/i915/intel_panel.c
 index 776249bab488..360ae203aacb 100644
 --- a/drivers/gpu/drm/i915/intel_panel.c
 +++ b/drivers/gpu/drm/i915/intel_panel.c
 @@ -398,6 +398,30 @@ intel_panel_detect(struct drm_device *dev)
 }
  }

 +/* Scale user_level in range [0..user_max] to [hw_min..hw_max]. */
 +static u32 scale_user_to_hw(struct intel_connector *connector,
 +   u32 user_level, u32 user_max)
 +{
 +   struct intel_panel *panel = connector-panel;
 +
 +   user_level = clamp(user_level, 0U, user_max);
 +
 +   return panel-backlight.min + user_level *
 +   (panel-backlight.max - panel-backlight.min) / user_max;
 +}
 +
 +/* Scale hw_level in range [hw_min..hw_max] to [0..user_max]. */
 +static u32 scale_hw_to_user(struct intel_connector *connector,
 +   u32 hw_level, u32 user_max)
 +{
 +   struct intel_panel *panel = connector-panel;
 +
 +   hw_level = clamp(hw_level, panel-backlight.min, 
 panel-backlight.max);
 +
 +   return (hw_level - 

Re: [Intel-gfx] [PATCH] drm/i915: Enable FBC on GEN7 by default

[Stéphane Marchesin]

On Tue, Mar 25, 2014 at 12:27 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Mon, Mar 24, 2014 at 06:21:22PM -0700, Ben Widawsky wrote:
 I am not clear why we've never enabled it by default for GEN7. Looking
 at the git hostiry, it seems Rodrigo disabled it by default, and it's
 never been turned on. Quite a few fixes have gone in over the past year,
 and I think many of us are running this successfully.

 If there is some reason we know of why we don't enable this by default
 on GEN7, then please ignore the patch, and forgive my laziness.

 Other than the major performance degredation due to our implementation,

That sounds interesting, can you elaborate on the performance
degradation? I haven't noticed any, but of course I don't know how
it's supposed to behave...

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

Re: [Intel-gfx] [PATCH] drm/i915: Enable FBC on GEN7 by default

[Stéphane Marchesin]

On Mon, Mar 24, 2014 at 6:21 PM, Ben Widawsky
benjamin.widaw...@linux.intel.com wrote:
 I am not clear why we've never enabled it by default for GEN7. Looking
 at the git hostiry, it seems Rodrigo disabled it by default, and it's
 never been turned on. Quite a few fixes have gone in over the past year,
 and I think many of us are running this successfully.

Did you try with a high resolution panel? I could never get IVB FBC to
be completely stable with a 2560x1700 panel...

Stéphane


 If there is some reason we know of why we don't enable this by default
 on GEN7, then please ignore the patch, and forgive my laziness.

 Cc: Rodrigo Vivi rodrigo.v...@gmail.com
 Signed-off-by: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/intel_pm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
 index a7da962..a9890df 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -512,7 +512,7 @@ void intel_update_fbc(struct drm_device *dev)
 adjusted_mode = intel_crtc-config.adjusted_mode;

 if (i915.enable_fbc  0 
 -   INTEL_INFO(dev)-gen = 7  !IS_HASWELL(dev)) {
 +   INTEL_INFO(dev)-gen = 6) {
 if (set_no_fbc_reason(dev_priv, FBC_CHIP_DEFAULT))
 DRM_DEBUG_KMS(disabled per chip default\n);
 goto out_disable;
 --
 1.9.1

 ___
 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

[Intel-gfx] [PATCH] drm/i915: Use the DVI clock limit in DVI mode

[Stéphane Marchesin]

When using HDMI, the 300MHz clock is legal, but when in DVI mode it's
definitely not. This causes issues when we send a 300MHz signal over a
DVI cable which is specced for 165MHz only. So when in DVI mode let's
limit the clock to 165MHz.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_hdmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index dd4fa35..0ac69f1 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -806,6 +806,10 @@ static int hdmi_portclock_limit(struct intel_hdmi *hdmi)
 {
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
 
+   /* If we are in DVI mode, the limit is 165MHz */
+   if (!hdmi-has_hdmi_sink)
+   return 165000;
+
if (IS_G4X(dev))
return 165000;
else if (IS_HASWELL(dev))
-- 
1.9.1.423.g4596e3a

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

Re: [Intel-gfx] [PATCH] drm/i915: Enable FBC on GEN7 by default

[Stéphane Marchesin]

On Mon, Mar 24, 2014 at 6:46 PM, Ben Widawsky b...@bwidawsk.net wrote:
 On Mon, Mar 24, 2014 at 06:41:47PM -0700, Stéphane Marchesin wrote:
 On Mon, Mar 24, 2014 at 6:21 PM, Ben Widawsky
 benjamin.widaw...@linux.intel.com wrote:
  I am not clear why we've never enabled it by default for GEN7. Looking
  at the git hostiry, it seems Rodrigo disabled it by default, and it's
  never been turned on. Quite a few fixes have gone in over the past year,
  and I think many of us are running this successfully.

 Did you try with a high resolution panel? I could never get IVB FBC to
 be completely stable with a 2560x1700 panel...

 Stéphane

 1600x900 is working fine. At my current laziness, that's the best I can
 test. I can try on a higher resolution tomorrow.  Perhaps the solution
 would be to disable if the resolution goes above a certain point.

 Honestly, I assumed there was a reason it was disabled, I just couldn't
 find it.

For what it's worth, it's fine for me up to 2k wide. Things seem to go
bad above that.

Stéphane



 
  If there is some reason we know of why we don't enable this by default
  on GEN7, then please ignore the patch, and forgive my laziness.
 
  Cc: Rodrigo Vivi rodrigo.v...@gmail.com
  Signed-off-by: Ben Widawsky b...@bwidawsk.net
  ---
   drivers/gpu/drm/i915/intel_pm.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_pm.c 
  b/drivers/gpu/drm/i915/intel_pm.c
  index a7da962..a9890df 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -512,7 +512,7 @@ void intel_update_fbc(struct drm_device *dev)
  adjusted_mode = intel_crtc-config.adjusted_mode;
 
  if (i915.enable_fbc  0 
  -   INTEL_INFO(dev)-gen = 7  !IS_HASWELL(dev)) {
  +   INTEL_INFO(dev)-gen = 6) {
  if (set_no_fbc_reason(dev_priv, FBC_CHIP_DEFAULT))
  DRM_DEBUG_KMS(disabled per chip default\n);
  goto out_disable;
  --
  1.9.1
 
  ___
  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

 --
 Ben Widawsky, 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 0/6] Intel Color Manager Framework

[Stéphane Marchesin]

On Fri, Feb 21, 2014 at 7:49 PM, Sharma, Shashank shashank.sha...@intel.com
 wrote:

On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrjälä 
 ville.syrj...@linux.intel.com wrote:

 On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
  Color manager is a new framework in i915 driver, which provides
  a unified interface for various color correction methods supported
  by intel hardwares. The high level overview of this change is:

 Would have been good to discuss this idea before implementing it. The
 plan is to use kms properties for this kind of stuff which allows us
 to hook it up with the upcoming atomic modeset API. Just yesterday there
 was some discussion on #dri-devel about exposing user settable blob
 properties even before the atomic modeset API lands (it was always the
 plan for the atomic modeset API anyway). So based on a cursory glance,
 this looks like it's going in the wrong direction.



 +1. We'e looking into hooking up color correction controls, and if the
 interface isn't standard our user space won't be portable across drivers.
 There are multiple reasons for using drm properties:

 - the KMS interface already provides a way to set the gamma ramp, which
 this code seems to replicate.



 The current KMS interface just initializes the gamma soft LUT palette
 registers, in 8 bit mode corresponding to unit gamma. It's impossible to
 apply accurate values corresponding to gamma=2.2 or 1.5 from KMS

 Because for that we need to program palette registers in 10.6 bit mode of
 hardware.


Then the existing interface should be extended. Otherwise you have two ways
to do the same thing...



   - the KMS interface allows us to name properties independently and
 enumerate them. It seems like right now you can't enumerate properties or
 guess what property 0 is. I'd rather set the Color conversion matrix
 than remember to set property 0 (and even then, I'm not really sure it
 exists).



 All the properties are getting enumerated in color manager register
 function. The framework defines proper identifiers and mapping for each
 property, and every property is having a corresponding soft-lut to be
 loaded with correction values.


Correct me if I'm wrong, but I don't see a way for user space to query the
presence/absence of a given property. KMS allows that.





 - you can reuse the get/set infrastructure which is already in place





 Another thing that came out of the discussion on irc is that we should
 standardize the properties. For example we could use a text file describing
 the name of the controls and the format of the data (something similar to
 the device tree bindings). That way user space can expect color
 conversion matrix to mean the same thing everywhere, to get the same data
 as input, and to work the same way on all platforms.

 If you can please have a look on the header file, we are almost doing the
 same thing, in form of a protocol.


This protocol however is not extensible. With the KMS interface I can
already do the following from user space:
- query the existence of a given property
- set each property in a portable fashion (for example the same gamma ramp
code works on all DRM drivers)
- easily match properties to a given crtc

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

Re: [Intel-gfx] [PATCH 0/6] Intel Color Manager Framework

[Stéphane Marchesin]

On Thu, Feb 20, 2014 at 5:11 AM, Ville Syrjälä 
ville.syrj...@linux.intel.com wrote:

 On Thu, Feb 20, 2014 at 06:07:21PM +0530, Shashank Sharma wrote:
  Color manager is a new framework in i915 driver, which provides
  a unified interface for various color correction methods supported
  by intel hardwares. The high level overview of this change is:

 Would have been good to discuss this idea before implementing it. The
 plan is to use kms properties for this kind of stuff which allows us
 to hook it up with the upcoming atomic modeset API. Just yesterday there
 was some discussion on #dri-devel about exposing user settable blob
 properties even before the atomic modeset API lands (it was always the
 plan for the atomic modeset API anyway). So based on a cursory glance,
 this looks like it's going in the wrong direction.


+1. We'e looking into hooking up color correction controls, and if the
interface isn't standard our user space won't be portable across drivers.
There are multiple reasons for using drm properties:
- the KMS interface already provides a way to set the gamma ramp, which
this code seems to replicate.
- the KMS interface allows us to name properties independently and
enumerate them. It seems like right now you can't enumerate properties or
guess what property 0 is. I'd rather set the Color conversion matrix
than remember to set property 0 (and even then, I'm not really sure it
exists).
- you can reuse the get/set infrastructure which is already in place

Another thing that came out of the discussion on irc is that we should
standardize the properties. For example we could use a text file describing
the name of the controls and the format of the data (something similar to
the device tree bindings). That way user space can expect color conversion
matrix to mean the same thing everywhere, to get the same data as input,
and to work the same way on all platforms.

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix fbc + rc6 combination on SNB

[Stéphane Marchesin]

On Tue, Nov 19, 2013 at 2:39 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Nov 19, 2013 at 3:08 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
 I'm just on going with another -collector update and since this patch
 fixes a bug I think it would be a good one to include.

 But since it was bikeshedded it is better to ask Ville and Chris if
 their comments was a NAck or I can consider to get for -collector.

 It's more a meh, since as long as we don't enable fbc by default it
 won't really benefit upstream much at all.

These two patches fix real FBC issues here, letting us enable it and
save power. I think it's worth considering them for inclusion.

Stéphane

 -Daniel
 --
 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
 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 2/2] [v2] drm/i915: Disable blt tracking of fbc when not used

[Stéphane Marchesin]

On Fri, Nov 1, 2013 at 5:04 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
 When not blitting to scanout, we can save some power by not tracking
 blits, and more importantly, unnecessarily invalidating lines which we
 don't care a bout.

 These instructions are explicitly spelled out in the spec, but it is how
 I expect it to work. Unfortunately, I do not have power data for this.

 v2: Don't advance the ring twice (Stéphane)
 Rename extra_dwords to dwrods (Stéphane)

 Cc: Stéphane Marchesin marc...@chromium.org
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

For both:
Tested-by: Stéphane Marchesin marc...@chromium.org
Reviewed-by: Stéphane Marchesin marc...@chromium.org

Stéphane

 ---
  drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +---
  1 file changed, 17 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
 b/drivers/gpu/drm/i915/intel_ringbuffer.c
 index ddd7681..8c6e9b2 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
 @@ -296,7 +296,8 @@ static int gen6_ring_fbc_flush(struct intel_ring_buffer 
 *ring)
 _MASKED_BIT_ENABLE(GEN6_BLITTER_FBC_NOTIFY));
 intel_ring_advance(ring);

 -   ring-fbc_dirty = false;
 +   /* We'll mark the fbc clean only after the operation has completed so 
 we
 +* can track when to disable the bit above */
 return 0;
  }

 @@ -642,11 +643,13 @@ gen6_add_request(struct intel_ring_buffer *ring)
 struct drm_device *dev = ring-dev;
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct intel_ring_buffer *useless;
 -   int i, ret;
 +   int i, ret, dwords = 4;

 +   if (ring-fbc_dirty  ring-id == BCS)
 +   dwords += 4;
 ret = intel_ring_begin(ring, ((I915_NUM_RINGS-1) *
   MBOX_UPDATE_DWORDS) +
 - 4);
 + dwords);
 if (ret)
 return ret;
  #undef MBOX_UPDATE_DWORDS
 @@ -661,6 +664,17 @@ gen6_add_request(struct intel_ring_buffer *ring)
 intel_ring_emit(ring, I915_GEM_HWS_INDEX  
 MI_STORE_DWORD_INDEX_SHIFT);
 intel_ring_emit(ring, ring-outstanding_lazy_seqno);
 intel_ring_emit(ring, MI_USER_INTERRUPT);
 +
 +   if (ring-fbc_dirty  ring-id == BCS) {
 +   intel_ring_emit(ring, MI_NOOP);
 +   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 +   intel_ring_emit(ring, GEN6_BLITTER_ECOSKPD);
 +   intel_ring_emit(ring,
 +   _MASKED_BIT_DISABLE(GEN6_BLITTER_FBC_NOTIFY));
 +
 +   ring-fbc_dirty = false;
 +   }
 +
 __intel_ring_advance(ring);

 return 0;
 --
 1.8.4.2

___
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: Use RCS flips on Ivybridge+

[Stéphane Marchesin]

On Mon, Aug 26, 2013 at 1:43 PM, Stéphane Marchesin
stephane.marche...@gmail.com wrote:



 On Mon, Aug 26, 2013 at 1:42 PM, Stéphane Marchesin
 stephane.marche...@gmail.com wrote:




 On Mon, Aug 26, 2013 at 12:58 PM, Chris Wilson ch...@chris-wilson.co.uk
 wrote:

 RCS flips do work on Iybridge+ so long as we can unmask the messages
 through DERRMR. However, there are quite a few workarounds mentioned
 regarding unmasking more than one event or triggering more than one
 message through DERRMR. Those workarounds in principle prevent us from
 performing pipelined flips (and asynchronous flips across multiple
 planes) and equally apply to the known good BCS ring. Given that it
 already appears to work, and also appears to work with unmasking all 3
 planes at once (and queuing flips across multiple planes), be brave.

 Bugzlla: https://bugs.freedesktop.org/show_bug.cgi?id=67600
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Lightly-tested-by: Stephane Marchesin marche...@icps.u-strasbg.fr


 You can go ahead and say Tested-by, I ran my usual tests for 3 hours and
 it didn't crash/show an issue. It would crash in ~10-30 minutes with the
 other patches.


 Oh actually this one is a bit different... Give me 3 hours :)


Tested-by: Stéphane Marchesin marc...@chromium.org

 Stéphane



 Stéphane


 Cc: Stephane Marchesin marche...@icps.u-strasbg.fr
 Cc: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/i915_reg.h  | 18 
  drivers/gpu/drm/i915/intel_display.c | 40
 
  2 files changed, 49 insertions(+), 9 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h
 b/drivers/gpu/drm/i915/i915_reg.h
 index c6f5009..df168f4 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -230,6 +230,7 @@
   *   address/value pairs. Don't overdue it, though, x = 2^4 must hold!
   */
  #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*x-1)
 +#define MI_STORE_REGISTER_MEM(x) MI_INSTR(0x24, 2*x-1)
  #define MI_FLUSH_DWMI_INSTR(0x26, 1) /* for GEN6 */
  #define   MI_FLUSH_DW_STORE_INDEX  (121)
  #define   MI_INVALIDATE_TLB(118)
 @@ -678,6 +679,23 @@
  #define   FPGA_DBG_RM_NOCLAIM  (131)

  #define DERRMR 0x44050
 +#define   DERRMR_PIPEA_SCANLINE(10)
 +#define   DERRMR_PIPEA_PRI_FLIP_DONE   (11)
 +#define   DERRMR_PIPEA_SPR_FLIP_DONE   (12)
 +#define   DERRMR_PIPEA_VBLANK  (13)
 +#define   DERRMR_PIPEA_HBLANK  (15)
 +#define   DERRMR_PIPEB_SCANLINE(18)
 +#define   DERRMR_PIPEB_PRI_FLIP_DONE   (19)
 +#define   DERRMR_PIPEB_SPR_FLIP_DONE   (110)
 +#define   DERRMR_PIPEB_VBLANK  (111)
 +#define   DERRMR_PIPEB_HBLANK  (113)
 +/* Note that PIPEC is not a simple translation of PIPEA/PIPEB */
 +#define   DERRMR_PIPEC_SCANLINE(114)
 +#define   DERRMR_PIPEC_PRI_FLIP_DONE   (115)
 +#define   DERRMR_PIPEC_SPR_FLIP_DONE   (120)
 +#define   DERRMR_PIPEC_VBLANK  (121)
 +#define   DERRMR_PIPEC_HBLANK  (122)
 +

  /* GM45+ chicken bits -- debug workaround bits that may be required
   * for various sorts of correct behavior.  The top 16 bits of each are
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index 9748dce..ffbcbd1 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -7826,12 +7826,6 @@ err:
 return ret;
  }

 -/*
 - * On gen7 we currently use the blit ring because (in early silicon at
 least)
 - * the render ring doesn't give us interrpts for page flip completion,
 which
 - * means clients will hang after the first flip is queued.  Fortunately
 the
 - * blit ring generates interrupts properly, so use it instead.
 - */
  static int intel_gen7_queue_flip(struct drm_device *dev,
  struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
 @@ -7839,9 +7833,13 @@ static int intel_gen7_queue_flip(struct drm_device
 *dev,
  {
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 -   struct intel_ring_buffer *ring = dev_priv-ring[BCS];
 +   struct intel_ring_buffer *ring;
 uint32_t plane_bit = 0;
 -   int ret;
 +   int len, ret;
 +
 +   ring = obj-ring;
 +   if (ring == NULL || ring-id != RCS)
 +   ring = dev_priv-ring[BCS];

 ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
 if (ret)
 @@ -7863,10 +7861,34 @@ static int intel_gen7_queue_flip(struct
 drm_device *dev,
 goto err_unpin;
 }

 -   ret = intel_ring_begin(ring, 4);
 +   len = 4;
 +   if (ring-id == RCS)
 +   len += 6;
 +
 +   ret = intel_ring_begin(ring, len);
 if (ret)
 goto err_unpin;

 +   /* Unmask the flip-done completion message. Note that the bspec
 says that
 +* we should do

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use RCS flips on Ivybridge+

[Stéphane Marchesin]

On Mon, Aug 26, 2013 at 12:58 PM, Chris Wilson ch...@chris-wilson.co.ukwrote:

 RCS flips do work on Iybridge+ so long as we can unmask the messages
 through DERRMR. However, there are quite a few workarounds mentioned
 regarding unmasking more than one event or triggering more than one
 message through DERRMR. Those workarounds in principle prevent us from
 performing pipelined flips (and asynchronous flips across multiple
 planes) and equally apply to the known good BCS ring. Given that it
 already appears to work, and also appears to work with unmasking all 3
 planes at once (and queuing flips across multiple planes), be brave.

 Bugzlla: https://bugs.freedesktop.org/show_bug.cgi?id=67600
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Lightly-tested-by: Stephane Marchesin marche...@icps.u-strasbg.fr


You can go ahead and say Tested-by, I ran my usual tests for 3 hours and it
didn't crash/show an issue. It would crash in ~10-30 minutes with the other
patches.

Stéphane


 Cc: Stephane Marchesin marche...@icps.u-strasbg.fr
 Cc: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/i915_reg.h  | 18 
  drivers/gpu/drm/i915/intel_display.c | 40
 
  2 files changed, 49 insertions(+), 9 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h
 b/drivers/gpu/drm/i915/i915_reg.h
 index c6f5009..df168f4 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -230,6 +230,7 @@
   *   address/value pairs. Don't overdue it, though, x = 2^4 must hold!
   */
  #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*x-1)
 +#define MI_STORE_REGISTER_MEM(x) MI_INSTR(0x24, 2*x-1)
  #define MI_FLUSH_DWMI_INSTR(0x26, 1) /* for GEN6 */
  #define   MI_FLUSH_DW_STORE_INDEX  (121)
  #define   MI_INVALIDATE_TLB(118)
 @@ -678,6 +679,23 @@
  #define   FPGA_DBG_RM_NOCLAIM  (131)

  #define DERRMR 0x44050
 +#define   DERRMR_PIPEA_SCANLINE(10)
 +#define   DERRMR_PIPEA_PRI_FLIP_DONE   (11)
 +#define   DERRMR_PIPEA_SPR_FLIP_DONE   (12)
 +#define   DERRMR_PIPEA_VBLANK  (13)
 +#define   DERRMR_PIPEA_HBLANK  (15)
 +#define   DERRMR_PIPEB_SCANLINE(18)
 +#define   DERRMR_PIPEB_PRI_FLIP_DONE   (19)
 +#define   DERRMR_PIPEB_SPR_FLIP_DONE   (110)
 +#define   DERRMR_PIPEB_VBLANK  (111)
 +#define   DERRMR_PIPEB_HBLANK  (113)
 +/* Note that PIPEC is not a simple translation of PIPEA/PIPEB */
 +#define   DERRMR_PIPEC_SCANLINE(114)
 +#define   DERRMR_PIPEC_PRI_FLIP_DONE   (115)
 +#define   DERRMR_PIPEC_SPR_FLIP_DONE   (120)
 +#define   DERRMR_PIPEC_VBLANK  (121)
 +#define   DERRMR_PIPEC_HBLANK  (122)
 +

  /* GM45+ chicken bits -- debug workaround bits that may be required
   * for various sorts of correct behavior.  The top 16 bits of each are
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index 9748dce..ffbcbd1 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -7826,12 +7826,6 @@ err:
 return ret;
  }

 -/*
 - * On gen7 we currently use the blit ring because (in early silicon at
 least)
 - * the render ring doesn't give us interrpts for page flip completion,
 which
 - * means clients will hang after the first flip is queued.  Fortunately
 the
 - * blit ring generates interrupts properly, so use it instead.
 - */
  static int intel_gen7_queue_flip(struct drm_device *dev,
  struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
 @@ -7839,9 +7833,13 @@ static int intel_gen7_queue_flip(struct drm_device
 *dev,
  {
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 -   struct intel_ring_buffer *ring = dev_priv-ring[BCS];
 +   struct intel_ring_buffer *ring;
 uint32_t plane_bit = 0;
 -   int ret;
 +   int len, ret;
 +
 +   ring = obj-ring;
 +   if (ring == NULL || ring-id != RCS)
 +   ring = dev_priv-ring[BCS];

 ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
 if (ret)
 @@ -7863,10 +7861,34 @@ static int intel_gen7_queue_flip(struct drm_device
 *dev,
 goto err_unpin;
 }

 -   ret = intel_ring_begin(ring, 4);
 +   len = 4;
 +   if (ring-id == RCS)
 +   len += 6;
 +
 +   ret = intel_ring_begin(ring, len);
 if (ret)
 goto err_unpin;

 +   /* Unmask the flip-done completion message. Note that the bspec
 says that
 +* we should do this for both the BCS and RCS, and that we must
 not unmask
 +* more than one flip event at any time (or ensure that one flip
 message
 +* can be sent by waiting for flip-done prior to queueing new
 flips).
 +* Experimentation says that BCS works despite DERRMR masking all
 +* flip-done 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use RCS flips on Ivybridge+

[Stéphane Marchesin]

On Mon, Aug 26, 2013 at 1:42 PM, Stéphane Marchesin 
stephane.marche...@gmail.com wrote:




 On Mon, Aug 26, 2013 at 12:58 PM, Chris Wilson 
 ch...@chris-wilson.co.ukwrote:

 RCS flips do work on Iybridge+ so long as we can unmask the messages
 through DERRMR. However, there are quite a few workarounds mentioned
 regarding unmasking more than one event or triggering more than one
 message through DERRMR. Those workarounds in principle prevent us from
 performing pipelined flips (and asynchronous flips across multiple
 planes) and equally apply to the known good BCS ring. Given that it
 already appears to work, and also appears to work with unmasking all 3
 planes at once (and queuing flips across multiple planes), be brave.

 Bugzlla: https://bugs.freedesktop.org/show_bug.cgi?id=67600
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Lightly-tested-by: Stephane Marchesin marche...@icps.u-strasbg.fr


 You can go ahead and say Tested-by, I ran my usual tests for 3 hours and
 it didn't crash/show an issue. It would crash in ~10-30 minutes with the
 other patches.


Oh actually this one is a bit different... Give me 3 hours :)

Stéphane



 Stéphane


 Cc: Stephane Marchesin marche...@icps.u-strasbg.fr
 Cc: Ben Widawsky b...@bwidawsk.net
 ---
  drivers/gpu/drm/i915/i915_reg.h  | 18 
  drivers/gpu/drm/i915/intel_display.c | 40
 
  2 files changed, 49 insertions(+), 9 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h
 b/drivers/gpu/drm/i915/i915_reg.h
 index c6f5009..df168f4 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -230,6 +230,7 @@
   *   address/value pairs. Don't overdue it, though, x = 2^4 must hold!
   */
  #define MI_LOAD_REGISTER_IMM(x)MI_INSTR(0x22, 2*x-1)
 +#define MI_STORE_REGISTER_MEM(x) MI_INSTR(0x24, 2*x-1)
  #define MI_FLUSH_DWMI_INSTR(0x26, 1) /* for GEN6 */
  #define   MI_FLUSH_DW_STORE_INDEX  (121)
  #define   MI_INVALIDATE_TLB(118)
 @@ -678,6 +679,23 @@
  #define   FPGA_DBG_RM_NOCLAIM  (131)

  #define DERRMR 0x44050
 +#define   DERRMR_PIPEA_SCANLINE(10)
 +#define   DERRMR_PIPEA_PRI_FLIP_DONE   (11)
 +#define   DERRMR_PIPEA_SPR_FLIP_DONE   (12)
 +#define   DERRMR_PIPEA_VBLANK  (13)
 +#define   DERRMR_PIPEA_HBLANK  (15)
 +#define   DERRMR_PIPEB_SCANLINE(18)
 +#define   DERRMR_PIPEB_PRI_FLIP_DONE   (19)
 +#define   DERRMR_PIPEB_SPR_FLIP_DONE   (110)
 +#define   DERRMR_PIPEB_VBLANK  (111)
 +#define   DERRMR_PIPEB_HBLANK  (113)
 +/* Note that PIPEC is not a simple translation of PIPEA/PIPEB */
 +#define   DERRMR_PIPEC_SCANLINE(114)
 +#define   DERRMR_PIPEC_PRI_FLIP_DONE   (115)
 +#define   DERRMR_PIPEC_SPR_FLIP_DONE   (120)
 +#define   DERRMR_PIPEC_VBLANK  (121)
 +#define   DERRMR_PIPEC_HBLANK  (122)
 +

  /* GM45+ chicken bits -- debug workaround bits that may be required
   * for various sorts of correct behavior.  The top 16 bits of each are
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index 9748dce..ffbcbd1 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -7826,12 +7826,6 @@ err:
 return ret;
  }

 -/*
 - * On gen7 we currently use the blit ring because (in early silicon at
 least)
 - * the render ring doesn't give us interrpts for page flip completion,
 which
 - * means clients will hang after the first flip is queued.  Fortunately
 the
 - * blit ring generates interrupts properly, so use it instead.
 - */
  static int intel_gen7_queue_flip(struct drm_device *dev,
  struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
 @@ -7839,9 +7833,13 @@ static int intel_gen7_queue_flip(struct drm_device
 *dev,
  {
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 -   struct intel_ring_buffer *ring = dev_priv-ring[BCS];
 +   struct intel_ring_buffer *ring;
 uint32_t plane_bit = 0;
 -   int ret;
 +   int len, ret;
 +
 +   ring = obj-ring;
 +   if (ring == NULL || ring-id != RCS)
 +   ring = dev_priv-ring[BCS];

 ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
 if (ret)
 @@ -7863,10 +7861,34 @@ static int intel_gen7_queue_flip(struct
 drm_device *dev,
 goto err_unpin;
 }

 -   ret = intel_ring_begin(ring, 4);
 +   len = 4;
 +   if (ring-id == RCS)
 +   len += 6;
 +
 +   ret = intel_ring_begin(ring, len);
 if (ret)
 goto err_unpin;

 +   /* Unmask the flip-done completion message. Note that the bspec
 says that
 +* we should do this for both the BCS and RCS, and that we must
 not unmask
 +* more than one flip event at any time (or ensure that one flip
 message

Re: [Intel-gfx] [PATCH] drm/i915: Use RCS flips on Ivybridge+

[Stéphane Marchesin]

On Tue, Aug 20, 2013 at 1:34 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 RCS flips do work on Iybridge+ so long as we can unmask the messages
 through DERRMR. However, there are quite a few workarounds mentioned
 regarding unmasking more than one event or triggering more than one
 message through DERRMR. Those workarounds in principle prevent us from
 performing pipelined flips (and asynchronous flips across multiple
 planes) and equally apply to the known good BCS ring. Given that it
 already appears to work, and also appears to work with unmasking all 3
 planes at once (and queuing flips across multiple planes), be brave.

 Bugzlla: https://bugs.freedesktop.org/show_bug.cgi?id=67600
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

Seems to work great here. Tested-by: Stéphane Marchesin marc...@chromium.org

 ---
  drivers/gpu/drm/i915/i915_reg.h  |   17 +
  drivers/gpu/drm/i915/intel_display.c |   45 
 +++---
  2 files changed, 53 insertions(+), 9 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index e2690ec..730510d 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -679,6 +679,23 @@
  #define   FPGA_DBG_RM_NOCLAIM  (131)

  #define DERRMR 0x44050
 +#define   DERRMR_PIPEA_SCANLINE(10)
 +#define   DERRMR_PIPEA_PRI_FLIP_DONE   (11)
 +#define   DERRMR_PIPEA_SPR_FLIP_DONE   (12)
 +#define   DERRMR_PIPEA_VBLANK  (13)
 +#define   DERRMR_PIPEA_HBLANK  (15)
 +#define   DERRMR_PIPEB_SCANLINE(18)
 +#define   DERRMR_PIPEB_PRI_FLIP_DONE   (19)
 +#define   DERRMR_PIPEB_SPR_FLIP_DONE   (110)
 +#define   DERRMR_PIPEB_VBLANK  (111)
 +#define   DERRMR_PIPEB_HBLANK  (113)
 +/* Note that PIPEC is not a simple translation of PIPEA/PIPEB */
 +#define   DERRMR_PIPEC_SCANLINE(114)
 +#define   DERRMR_PIPEC_PRI_FLIP_DONE   (115)
 +#define   DERRMR_PIPEC_SPR_FLIP_DONE   (120)
 +#define   DERRMR_PIPEC_VBLANK  (121)
 +#define   DERRMR_PIPEC_HBLANK  (122)
 +

  /* GM45+ chicken bits -- debug workaround bits that may be required
   * for various sorts of correct behavior.  The top 16 bits of each are
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 727a123..55c9b39 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -7653,12 +7653,6 @@ err:
 return ret;
  }

 -/*
 - * On gen7 we currently use the blit ring because (in early silicon at least)
 - * the render ring doesn't give us interrpts for page flip completion, which
 - * means clients will hang after the first flip is queued.  Fortunately the
 - * blit ring generates interrupts properly, so use it instead.
 - */
  static int intel_gen7_queue_flip(struct drm_device *dev,
  struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
 @@ -7666,9 +7660,13 @@ static int intel_gen7_queue_flip(struct drm_device 
 *dev,
  {
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 -   struct intel_ring_buffer *ring = dev_priv-ring[BCS];
 +   struct intel_ring_buffer *ring;
 uint32_t plane_bit = 0;
 -   int ret;
 +   int len, ret;
 +
 +   ring = obj-ring;
 +   if (ring == NULL || ring-id != RCS)
 +   ring = dev_priv-ring[BCS];

 ret = intel_pin_and_fence_fb_obj(dev, obj, ring);
 if (ret)
 @@ -7690,10 +7688,39 @@ static int intel_gen7_queue_flip(struct drm_device 
 *dev,
 goto err_unpin;
 }

 -   ret = intel_ring_begin(ring, 4);
 +   len = 4;
 +   if (ring-id == RCS)
 +   len += 6;
 +
 +   ret = intel_ring_begin(ring, len);
 if (ret)
 goto err_unpin;

 +   /* Unmask the flip-done completion message. Note that the bspec says 
 that
 +* we should do this for both the BCS and RCS, and that we must not 
 unmask
 +* more than one flip event at any time (or ensure that one flip 
 message
 +* can be sent by waiting for flip-done prior to queueing new flips).
 +* Experimentation says that BCS works despite DERRMR masking all
 +* flip-done completion events and that unmasking all planes at once
 +* for the RCS also doesn't appear to drop events. Setting the DERRMR
 +* to zero does lead to lockups within MI_DISPLAY_FLIP.
 +*/
 +   if (ring-id == RCS) {
 +   struct { /* XXX This is quite rude! */
 +   struct drm_i915_gem_object *scratch;
 +   } *priv = ring-private;
 +   u32 addr = i915_gem_obj_ggtt_offset(priv-scratch) + 128;
 +
 +   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 +   intel_ring_emit(ring, DERRMR);
 +   intel_ring_emit(ring

Re: [Intel-gfx] [PATCH] drm/i915: Don't load context at driver init time on SNB

[Stéphane Marchesin]

On Tue, Aug 13, 2013 at 1:11 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
 On Mon, Aug 12, 2013 at 10:33:37AM -0700, Stéphane Marchesin wrote:
 On Fri, Aug 9, 2013 at 9:55 PM, Ben Widawsky b...@bwidawsk.net wrote:
  On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote:
  This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
  (drm/i915: load boot context at driver init time)
 
  This bit breaks hardware video decode for me after resume.
 
  Signed-off-by: Stéphane Marchesin marc...@chromium.org
  ---
   drivers/gpu/drm/i915/intel_pm.c | 4 
   1 file changed, 4 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_pm.c 
  b/drivers/gpu/drm/i915/intel_pm.c
  index f895d15..ffa4ab2 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -4614,10 +4614,6 @@ static void gen6_init_clock_gating(struct 
  drm_device *dev)
   ILK_DPARBUNIT_CLOCK_GATE_ENABLE  |
   ILK_DPFDUNIT_CLOCK_GATE_ENABLE);
 
  - /* WaMbcDriverBootEnable:snb */
  - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) |
  -GEN6_MBCTL_ENABLE_BOOT_FETCH);
  -
g4x_disable_trickle_feed(dev);
 
/* The default value should be 0x200 according to docs, but the two
 
  I was looking at this a bit with Stéphane. One thing we both see is that
  the bit isn't sticking as it should. Clearly doing the write is having
  an effect, but something is seriously wrong. Writing the bit manually
  with IGT does make the bit stick.
 
  Stéphane, could you try to write the bit with IGT before and after
  resume, and see if it helps?

 It doesn't seem to stick, and so seems to have no effect.

 The confusing thing is that video decode works fine before suspend,
 even though that reg is 0. And after resume, it is broken, and that
 reg is still 0. So something else is going on. Maybe this reg is
 write-once-ever?

 BSpec says This Bit is cleared by the Hardware once the Boot fetch is
 complete.

So it seems like the boot fetch doesn't work correctly, but still
clears the bit?

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

[Intel-gfx] [PATCH 2/2] drm/i915: tune the RC6 threshold for stability

[Stéphane Marchesin]

It's basically the same deal as the RC6+ issues on ivy bridge
except this time with RC6 on sandy bridge. Like last time the
core of the issue is that the timings don't work 100% with our
voltage regulator. So from time to time, the kernel will print
a warning message about the GPU not getting out of RC6. In
particular, I found this fairly easy to reproduce during
suspend/resume.

Changing the threshold to 125000 instead of 5 seems to fix
the issue. The previous patch used 15 but as it turns out
this doesn't work everywhere. After getting such a machine, I
bisected the highest value which works, which is 125000, so here
it is.

I also measured the idle power usage before/after this patch and
didn't see a difference on a sandy bridge laptop. On haswell and
up, it makes a big difference, so we want to keep it at 50k
there. It also seems like haswell doesn't have the RC6 issues
that sandy bridge has so the 50k value is fine.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_pm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 51a2a60..71839f8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3250,7 +3250,10 @@ static void gen6_enable_rps(struct drm_device *dev)
 
I915_WRITE(GEN6_RC_SLEEP, 0);
I915_WRITE(GEN6_RC1e_THRESHOLD, 1000);
-   I915_WRITE(GEN6_RC6_THRESHOLD, 5);
+   if (INTEL_INFO(dev)-gen = 6 || IS_IVYBRIDGE(dev))
+   I915_WRITE(GEN6_RC6_THRESHOLD, 125000);
+   else
+   I915_WRITE(GEN6_RC6_THRESHOLD, 5);
I915_WRITE(GEN6_RC6p_THRESHOLD, 15);
I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */
 
-- 
1.8.3

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

Re: [Intel-gfx] [PATCH] drm/i915: Don't load context at driver init time on SNB

[Stéphane Marchesin]

On Fri, Aug 9, 2013 at 9:55 PM, Ben Widawsky b...@bwidawsk.net wrote:
 On Fri, Aug 09, 2013 at 08:32:54PM -0700, Stéphane Marchesin wrote:
 This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
 (drm/i915: load boot context at driver init time)

 This bit breaks hardware video decode for me after resume.

 Signed-off-by: Stéphane Marchesin marc...@chromium.org
 ---
  drivers/gpu/drm/i915/intel_pm.c | 4 
  1 file changed, 4 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_pm.c 
 b/drivers/gpu/drm/i915/intel_pm.c
 index f895d15..ffa4ab2 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -4614,10 +4614,6 @@ static void gen6_init_clock_gating(struct drm_device 
 *dev)
  ILK_DPARBUNIT_CLOCK_GATE_ENABLE  |
  ILK_DPFDUNIT_CLOCK_GATE_ENABLE);

 - /* WaMbcDriverBootEnable:snb */
 - I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) |
 -GEN6_MBCTL_ENABLE_BOOT_FETCH);
 -
   g4x_disable_trickle_feed(dev);

   /* The default value should be 0x200 according to docs, but the two

 I was looking at this a bit with Stéphane. One thing we both see is that
 the bit isn't sticking as it should. Clearly doing the write is having
 an effect, but something is seriously wrong. Writing the bit manually
 with IGT does make the bit stick.

 Stéphane, could you try to write the bit with IGT before and after
 resume, and see if it helps?

It doesn't seem to stick, and so seems to have no effect.

The confusing thing is that video decode works fine before suspend,
even though that reg is 0. And after resume, it is broken, and that
reg is still 0. So something else is going on. Maybe this reg is
write-once-ever?

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

[Intel-gfx] [PATCH] drm/i915: Don't load context at driver init time on SNB

[Stéphane Marchesin]

This is a partial revert of b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
(drm/i915: load boot context at driver init time)

This bit breaks hardware video decode for me after resume.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_pm.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f895d15..ffa4ab2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4614,10 +4614,6 @@ static void gen6_init_clock_gating(struct drm_device 
*dev)
   ILK_DPARBUNIT_CLOCK_GATE_ENABLE  |
   ILK_DPFDUNIT_CLOCK_GATE_ENABLE);
 
-   /* WaMbcDriverBootEnable:snb */
-   I915_WRITE(GEN6_MBCTL, I915_READ(GEN6_MBCTL) |
-  GEN6_MBCTL_ENABLE_BOOT_FETCH);
-
g4x_disable_trickle_feed(dev);
 
/* The default value should be 0x200 according to docs, but the two
-- 
1.8.3

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

[Intel-gfx] [PATCH 1/3] drm/gma500: Remove useless define

[Stéphane Marchesin]

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 82430ad..d691a3a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -52,8 +52,6 @@ struct cdv_intel_clock_t {
int p;
 };
 
-#define INTEL_P2_NUM 2
-
 struct cdv_intel_limit_t {
struct cdv_intel_range_t dot, vco, n, m, m1, m2, p, p1;
struct cdv_intel_p2_t p2;
-- 
1.8.3

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

[Intel-gfx] [PATCH 2/3] drm/i915: Remove useless define

[Stéphane Marchesin]

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_display.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5fb3058..37b33c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -54,7 +54,6 @@ typedef struct {
int p2_slow, p2_fast;
 } intel_p2_t;
 
-#define INTEL_P2_NUM 2
 typedef struct intel_limit intel_limit_t;
 struct intel_limit {
intel_range_t   dot, vco, n, m, m1, m2, p, p1;
-- 
1.8.3

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

[Intel-gfx] [PATCH 3/3] drm: Remove drm_mode_validate_clocks

[Stéphane Marchesin]

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/drm_modes.c | 37 -
 include/drm/drm_crtc.h  |  3 ---
 2 files changed, 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a6729bf..504a602 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -923,43 +923,6 @@ void drm_mode_validate_size(struct drm_device *dev,
 EXPORT_SYMBOL(drm_mode_validate_size);
 
 /**
- * drm_mode_validate_clocks - validate modes against clock limits
- * @dev: DRM device
- * @mode_list: list of modes to check
- * @min: minimum clock rate array
- * @max: maximum clock rate array
- * @n_ranges: number of clock ranges (size of arrays)
- *
- * LOCKING:
- * Caller must hold a lock protecting @mode_list.
- *
- * Some code may need to check a mode list against the clock limits of the
- * device in question.  This function walks the mode list, testing to make
- * sure each mode falls within a given range (defined by @min and @max
- * arrays) and sets @mode-status as needed.
- */
-void drm_mode_validate_clocks(struct drm_device *dev,
- struct list_head *mode_list,
- int *min, int *max, int n_ranges)
-{
-   struct drm_display_mode *mode;
-   int i;
-
-   list_for_each_entry(mode, mode_list, head) {
-   bool good = false;
-   for (i = 0; i  n_ranges; i++) {
-   if (mode-clock = min[i]  mode-clock = max[i]) {
-   good = true;
-   break;
-   }
-   }
-   if (!good)
-   mode-status = MODE_CLOCK_RANGE;
-   }
-}
-EXPORT_SYMBOL(drm_mode_validate_clocks);
-
-/**
  * drm_mode_prune_invalid - remove invalid modes from mode list
  * @dev: DRM device
  * @mode_list: list of modes to check
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fa12a2f..32e0820 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -930,9 +930,6 @@ extern void drm_mode_list_concat(struct list_head *head,
 extern void drm_mode_validate_size(struct drm_device *dev,
   struct list_head *mode_list,
   int maxX, int maxY, int maxPitch);
-extern void drm_mode_validate_clocks(struct drm_device *dev,
-struct list_head *mode_list,
-int *min, int *max, int n_ranges);
 extern void drm_mode_prune_invalid(struct drm_device *dev,
   struct list_head *mode_list, bool verbose);
 extern void drm_mode_sort(struct list_head *mode_list);
-- 
1.8.3

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

Re: [Intel-gfx] [PATCH] Lower threshold for pixel doubling.

[Stéphane Marchesin]

On Thu, Jul 25, 2013 at 11:01 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Tue, Jun 25, 2013 at 1:28 AM, Stuart Abercrombie
 sabercrom...@google.com wrote:
 This is with the patch.

 Hm, nothing really interesting bug I've finally gotten around to some
 doc reading and they seem to insist pretty hard that double wide mode
 on pipe A only works if we have pipe A linked up with cursor/plane A.
 But on gen3 mobile we switch pipesplanes and Stéphane said on irc
 that you've changed the logic in there a bit. Can you please check
 whether you're still using plane B for pipe A or if there's something
 broken?

We had to change that logic because 3.8 doesn't display anything by
default on that machine (the autodetect logic is broken, as I reported
in
http://lists.freedesktop.org/archives/dri-devel/2013-March/036070.html
). Do you want to address that issue first?

Stéphane

 -Daniel



 On Sun, Jun 23, 2013 at 11:59 PM, Daniel Vetter dan...@ffwll.ch wrote:

 On Sat, Jun 22, 2013 at 12:52 AM, Stuart Abercrombie
 sabercrom...@google.com wrote:
  Maybe I missed something, but I didn't see a response to this.  Can we
  get
  this fix in?

 Sorry for the delay, I've lost track of this. Can you please boot with
 drm.debug=0xe and attach the full dmesg (with or without your patch)?
 -Daniel

 
 
  On Wed, May 29, 2013 at 9:22 AM, Stuart Abercrombie
  sabercrom...@google.com wrote:
 
  Without this change I saw PIPE_FIFO_UNDERRUN_STATUS set in PIPEASTAT,
  which I took to indicate an underrun problem.
 
  Here's what I found with other modes on this monitor:
 
  1920x1200 works with pixel doubling enabled. Pixel clock 193.2 MHz.
  2048x1152 works with pixel doubling enabled. Pixel clock 198.0 MHz.
  1600x1200 works with pixel doubling disabled. Pixel clock 162.0 MHz.
  2048x1280 fails with pixel doubling disabled. PIxel clock 174.2 MHz..
 
  Based on this, it seems the threshold needs to be be between 162.0MHz
  and
  174.2MHz, whereas currently it's at 180MHz.  The change puts it at
  170MHz.
 
  Stuart
 
 
  On Wed, May 29, 2013 at 8:22 AM, Daniel Vetter dan...@ffwll.ch wrote:
 
  On Tue, May 28, 2013 at 10:39:07AM -0700, Stuart Abercrombie wrote:
   Any comments?
  
   Without this, plugging one of the older Chromebook models into a
   Dell
   U3011
   monitor produces a garbled display at the default 2048x1280
   resolution.
  
   The original threshold was apparently fairly arbitrary:
  
  
  
   http://cgit.freedesktop.org/~anholt/xf86-video-intel/commit/?id=8fcf9a81179ee8577ddab5e904c58fbfd14cf59c
 
  Do you see any pipe underruns without this patch? There are some
  not-yet
  implemented tricks we should be pulling around re-splitting DSP_ARB
  fifo
  entries, which tend to totally kill high-res modes.
  -Daniel
 
   .
  
   Stuart
  
  
   On Mon, May 20, 2013 at 11:15 AM, Stuart Abercrombie 
   sabercrom...@chromium.org wrote:
  
90% of core speed (=180MHz dot clock) is too high for 2048x1280 to
get
pixel doubling on Pineview, which it needs to avoid underruns, so
lower this to 85%.
   
Signed-off-by: Stuart Abercrombie sabercrom...@chromium.org
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
   
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index efe8299..9c924e9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4564,14 +4564,14 @@ static void i9xx_set_pipeconf(struct
intel_crtc
*intel_crtc)
pipeconf = I915_READ(PIPECONF(intel_crtc-pipe));
   
if (intel_crtc-pipe == 0  INTEL_INFO(dev)-gen  4) {
-   /* Enable pixel doubling when the dot clock is 
90%
of
the (display)
+   /* Enable pixel doubling when the dot clock is 
85%
of
the (display)
 * core speed.
 *
 * XXX: No double-wide on 915GM pipe B. Is that
the
only
reason for the
 * pipe == 0 check?
 */
if (intel_crtc-config.requested_mode.clock 
-   dev_priv-display.get_display_clock_speed(dev)
*
9 /
10)
+   dev_priv-display.get_display_clock_speed(dev)
*
17 /
20)
pipeconf |= PIPECONF_DOUBLE_WIDE;
else
pipeconf = ~PIPECONF_DOUBLE_WIDE;
--
1.8.2.1
   
   
 
   ___
   Intel-gfx mailing list
   Intel-gfx@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 
  --
  Daniel Vetter
  Software Engineer, Intel Corporation
  +41 (0) 79 365 57 48 - http://blog.ffwll.ch
 
 
 



 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch





 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 

[Intel-gfx] [PATCH] drm/i915: Preserve the DDI_A_4_LANES bit from the bios

[Stéphane Marchesin]

Otherwise the DDI_A_4_LANES bit gets lost and we can't use  2 lanes
on eDP. This fixes eDP on hsw with  2 lanes.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_ddi.c | 2 +-
 drivers/gpu/drm/i915/intel_dp.c  | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 324211a..5e3f97b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1348,7 +1348,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
 
intel_dig_port-port = port;
intel_dig_port-port_reversal = I915_READ(DDI_BUF_CTL(port)) 
-   DDI_BUF_PORT_REVERSAL;
+   (DDI_BUF_PORT_REVERSAL | DDI_A_4_LANES);
intel_dig_port-dp.output_reg = DDI_BUF_CTL(port);
 
intel_encoder-type = INTEL_OUTPUT_UNKNOWN;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b739712..a1d838c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -834,10 +834,11 @@ intel_dp_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
 * configuration happens (oddly) in ironlake_pch_enable
 */
 
-   /* Preserve the BIOS-computed detected bit. This is
+   /* Preserve the BIOS-computed detected and 4 lanes bits. This is
 * supposed to be read-only.
 */
-   intel_dp-DP = I915_READ(intel_dp-output_reg)  DP_DETECTED;
+   intel_dp-DP = I915_READ(intel_dp-output_reg) 
+  (DP_DETECTED | DDI_A_4_LANES);
 
/* Handle DP bits in common between all three register formats */
intel_dp-DP |= DP_VOLTAGE_0_4 | DP_PRE_EMPHASIS_0;
-- 
1.8.3

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

[Intel-gfx] [PATCH] drm/i915: Preserve the DDI_A_4_LANES bit from the bios

[Stéphane Marchesin]

Otherwise the DDI_A_4_LANES bit gets lost and we can't use  2 lanes
on eDP. This fixes eDP on hsw with  2 lanes.

Also s/port_reversal/saved_port_bits/ since the current name is
confusing.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_ddi.c | 10 ++
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 324211a..b042ee5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -301,7 +301,7 @@ static void intel_ddi_mode_set(struct drm_encoder *encoder,
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder);
 
-   intel_dp-DP = intel_dig_port-port_reversal |
+   intel_dp-DP = intel_dig_port-saved_port_bits |
   DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW;
intel_dp-DP |= DDI_PORT_WIDTH(intel_dp-lane_count);
 
@@ -1109,7 +1109,8 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder)
 * enabling the port.
 */
I915_WRITE(DDI_BUF_CTL(port),
-  intel_dig_port-port_reversal | DDI_BUF_CTL_ENABLE);
+  intel_dig_port-saved_port_bits |
+  DDI_BUF_CTL_ENABLE);
} else if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 
@@ -1347,8 +1348,9 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_encoder-get_config = intel_ddi_get_config;
 
intel_dig_port-port = port;
-   intel_dig_port-port_reversal = I915_READ(DDI_BUF_CTL(port)) 
-   DDI_BUF_PORT_REVERSAL;
+   intel_dig_port-saved_port_bits = I915_READ(DDI_BUF_CTL(port)) 
+ (DDI_BUF_PORT_REVERSAL |
+  DDI_A_4_LANES);
intel_dig_port-dp.output_reg = DDI_BUF_CTL(port);
 
intel_encoder-type = INTEL_OUTPUT_UNKNOWN;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c8c9b6f..b7d6e09 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -504,7 +504,7 @@ struct intel_dp {
 struct intel_digital_port {
struct intel_encoder base;
enum port port;
-   u32 port_reversal;
+   u32 saved_port_bits;
struct intel_dp dp;
struct intel_hdmi hdmi;
 };
-- 
1.8.3

___
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: repin bound framebuffers on resume

[Stéphane Marchesin]

On Wed, Jun 12, 2013 at 3:06 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Wed, 12 Jun 2013 00:48:25 +0100
 Chris Wilson ch...@chris-wilson.co.uk wrote:

 On Tue, Jun 11, 2013 at 04:01:21PM -0700, Stéphane Marchesin wrote:
 
  On Tue, Jun 11, 2013 at 3:57 PM, Chris Wilson ch...@chris-wilson.co.uk 
  wrote:
   On Tue, Jun 11, 2013 at 03:49:27PM -0700, Stéphane Marchesin wrote:
   During suspend all fences are reset, including their pin_count which
   is reset to 0. However a framebuffer can be bound across
   suspend/resume, which means that when the buffer is unbound after
   resume, the pin count for the buffer will be negative. Since the
   fence pin count is now negative when available and zero when in use,
   the buffer's fence will get recycled when the fence is in use which
   is the opposite of what we want. The visible effect is that since the
   fence is recycled the tiling mode goes away while the buffer is being
   displayed and we get lines/screens of garbage.
  
   To fix this, we repin the fences for all bound fbs on resume, which
   ensures the pin count is right.
  
   Yikes. So why do we not just keep the fences alive during suspend (not
   touching their pin_count), and then just iterate over the list of fences
   rewriting the register as required upon resume? That would seem less
   error prone than trying to reconstruct the lost pin_count.
 
  I suspect they'd need to be saved/restored at the hw level as well,
  which AFAICS isn't happening today...

 Ugh, I introduced this bug 30 months ago - saved by the VT switch on
 resume. But we can restore the fences from dev_priv-fence_regs...
 Actually we have a very similar problem after a GPU reset where we
 should restore fences for pinned objects (i.e. the scanout). The patch
 to fix both looks fairly straightforward.

 To be clear, this only affects gen3 right?  For gen4+ we don't need the
 fences for scanout since we have a bit in the plane control...

Yup I've only ever seen the issue on gen3.

Anyway, what should we do about this? Should I make another patch
where I save/restore the fence regs instead?

Stéphane


 Or are we failing to fault on a previously mapped scanout too?  If so,
 we'd need to cover more than just scanout here.

 --
 Jesse Barnes, 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/2] drm/i915: tune the RC6 threshold for stability

[Stéphane Marchesin]

On Wed, Jun 12, 2013 at 2:41 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Jun 11, 2013 at 03:49:26PM -0700, Stéphane Marchesin wrote:
 It's basically the same deal as the RC6+ issues on ivy bridge
 except this time with RC6 on sandy bridge. Like last time the
 core of the issue is that the timings don't work 100% with our
 voltage regulator. So from time to time, the kernel will print
 a warning message about the GPU not getting out of RC6. In
 particular, I found this fairly easy to reproduce during
 suspend/resume.

 Changing the threshold to 15 instead of 5 seems to fix
 the issue.

 I also measured the idle power usage before/after this patch and
 didn't see a difference on a sandy bridge laptop.

 Signed-off-by: Stéphane Marchesin marc...@chromium.org

 One magic number for another with no idea what is blowing up - I fear we
 are just changing the frequency of the hang. I've pinged a number of snb
 rc6 bug reports to see if we get a bite.

Yup, if only Intel documented those registers :)

Stéphane


 FWIW,
 Acked-by: Chris Wilson ch...@chris-wilson.co.uk
 -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

[Intel-gfx] [PATCH 1/2] drm/i915: tune the RC6 threshold for stability

[Stéphane Marchesin]

It's basically the same deal as the RC6+ issues on ivy bridge
except this time with RC6 on sandy bridge. Like last time the
core of the issue is that the timings don't work 100% with our
voltage regulator. So from time to time, the kernel will print
a warning message about the GPU not getting out of RC6. In
particular, I found this fairly easy to reproduce during
suspend/resume.

Changing the threshold to 15 instead of 5 seems to fix
the issue.

I also measured the idle power usage before/after this patch and
didn't see a difference on a sandy bridge laptop.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index aa01128..52fe8f7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2577,7 +2577,7 @@ static void gen6_enable_rps(struct drm_device *dev)
 
I915_WRITE(GEN6_RC_SLEEP, 0);
I915_WRITE(GEN6_RC1e_THRESHOLD, 1000);
-   I915_WRITE(GEN6_RC6_THRESHOLD, 5);
+   I915_WRITE(GEN6_RC6_THRESHOLD, 15);
I915_WRITE(GEN6_RC6p_THRESHOLD, 15);
I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */
 
-- 
1.8.3

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

[Intel-gfx] [PATCH 2/2] drm/i915: repin bound framebuffers on resume

[Stéphane Marchesin]

During suspend all fences are reset, including their pin_count which
is reset to 0. However a framebuffer can be bound across
suspend/resume, which means that when the buffer is unbound after
resume, the pin count for the buffer will be negative. Since the
fence pin count is now negative when available and zero when in use,
the buffer's fence will get recycled when the fence is in use which
is the opposite of what we want. The visible effect is that since the
fence is recycled the tiling mode goes away while the buffer is being
displayed and we get lines/screens of garbage.

To fix this, we repin the fences for all bound fbs on resume, which
ensures the pin count is right.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/i915_drv.c  |  2 ++
 drivers/gpu/drm/i915/intel_display.c | 32 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 3 files changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a2e4953..b8e82ab 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -643,6 +643,8 @@ static int __i915_drm_thaw(struct drm_device *dev)
/* We need working interrupts for modeset enabling ... */
drm_irq_install(dev);
 
+   /* Repin all live fences before resuming */
+   intel_repin_fences(dev);
intel_modeset_init_hw(dev);
 
drm_modeset_lock_all(dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 56746dc..4bf3240 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2051,6 +2051,38 @@ void intel_unpin_fb_obj(struct drm_i915_gem_object *obj)
i915_gem_object_unpin(obj);
 }
 
+/*
+ * Repin the fences for all currently bound fbs. During suspend i915_drm_freeze
+ * calls i915_gem_reset, which in turn calls i915_gem_reset_fences, which
+ * resets the fence pin_counts to 0. So on resume we can call this function to
+ * restore the fences on bound framebuffers.
+ */
+void intel_repin_fences(struct drm_device *dev)
+{
+   struct drm_crtc *crtc;
+   struct drm_i915_gem_object *obj;
+   int ret;
+
+   mutex_lock(mode_config-mutex);
+   list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
+   if (!crtc || !crtc-fb)
+   continue;
+   obj = to_intel_framebuffer(crtc-fb)-obj;
+   if (!obj)
+   continue;
+
+   /* Install a fence for tiled scan-out. */
+   if (obj-tiling_mode != I915_TILING_NONE) {
+   ret = i915_gem_object_get_fence(obj);
+   if (ret)
+   DRM_ERROR(Couldn't get a fence\n);
+   else
+   i915_gem_object_pin_fence(obj);
+   }
+   }
+   mutex_unlock(mode_config-mutex);
+}
+
 /* Computes the linear offset to the base tile and adjusts x, y. bytes per 
pixel
  * is assumed to be a power-of-two. */
 unsigned long intel_gen4_compute_page_offset(int *x, int *y,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 624a9e6..b5395ed 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -630,6 +630,7 @@ extern int intel_pin_and_fence_fb_obj(struct drm_device 
*dev,
  struct drm_i915_gem_object *obj,
  struct intel_ring_buffer *pipelined);
 extern void intel_unpin_fb_obj(struct drm_i915_gem_object *obj);
+extern void intel_repin_fences(struct drm_device *dev);
 
 extern int intel_framebuffer_init(struct drm_device *dev,
  struct intel_framebuffer *ifb,
-- 
1.8.3

___
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: repin bound framebuffers on resume

[Stéphane Marchesin]

On Tue, Jun 11, 2013 at 3:57 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Jun 11, 2013 at 03:49:27PM -0700, Stéphane Marchesin wrote:
 During suspend all fences are reset, including their pin_count which
 is reset to 0. However a framebuffer can be bound across
 suspend/resume, which means that when the buffer is unbound after
 resume, the pin count for the buffer will be negative. Since the
 fence pin count is now negative when available and zero when in use,
 the buffer's fence will get recycled when the fence is in use which
 is the opposite of what we want. The visible effect is that since the
 fence is recycled the tiling mode goes away while the buffer is being
 displayed and we get lines/screens of garbage.

 To fix this, we repin the fences for all bound fbs on resume, which
 ensures the pin count is right.

 Yikes. So why do we not just keep the fences alive during suspend (not
 touching their pin_count), and then just iterate over the list of fences
 rewriting the register as required upon resume? That would seem less
 error prone than trying to reconstruct the lost pin_count.

I suspect they'd need to be saved/restored at the hw level as well,
which AFAICS isn't happening today...

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

Re: [Intel-gfx] [PATCH xf96-video-intel] DRI2GetMSC: Do not send a bogus ust when no drawable is not displayed

[Stéphane Marchesin]

On Fri, Mar 29, 2013 at 2:07 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Mar 29, 2013 at 01:54:37PM +0800, Daniel Kurtz wrote:
 According to the opengl glx_sync_control spec, the Unadjusted System Time
 (or UST) is a 64-bit monotonically increasing counter that is available
 throughout the system:
 http://www.opengl.org/registry/specs/OML/glx_sync_control.txt

 Therefore, sending 0, even in this corner case, is out of spec.
 Instead, just return FALSE indicating that the operation could not be
 completed.

 The problem is that ends up sending BadDrawable back to the client,
 which ends up killing many clients and a compositor or two due to the
 unexpected error.

 Would you prefer querying pipe 0 in this case for the UST?

For us it comes down to the fact that we'd like something monotonous.
So yes querying pipe 0 could work if it's enabled. But I wonder what
do you do when you have no enabled pipe though? Return the last UST?

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

Re: [Intel-gfx] [PATCH xf96-video-intel] DRI2GetMSC: Do not send a bogus ust when no drawable is not displayed

[Stéphane Marchesin]

On Fri, Mar 29, 2013 at 5:54 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Fri, Mar 29, 2013 at 03:13:35AM -0700, Stéphane Marchesin wrote:
 On Fri, Mar 29, 2013 at 2:07 AM, Chris Wilson ch...@chris-wilson.co.uk 
 wrote:
  On Fri, Mar 29, 2013 at 01:54:37PM +0800, Daniel Kurtz wrote:
  According to the opengl glx_sync_control spec, the Unadjusted System Time
  (or UST) is a 64-bit monotonically increasing counter that is available
  throughout the system:
  http://www.opengl.org/registry/specs/OML/glx_sync_control.txt
 
  Therefore, sending 0, even in this corner case, is out of spec.
  Instead, just return FALSE indicating that the operation could not be
  completed.
 
  The problem is that ends up sending BadDrawable back to the client,
  which ends up killing many clients and a compositor or two due to the
  unexpected error.
 
  Would you prefer querying pipe 0 in this case for the UST?

 For us it comes down to the fact that we'd like something monotonous.
 So yes querying pipe 0 could work if it's enabled. But I wonder what
 do you do when you have no enabled pipe though? Return the last UST?

 That's a problem as we would need a running pipe, which is not
 guaranteed. I wonder if CLOCK_MONOTONIC would suffice?

Yeah that's what I had in mind. Would that work for you?

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

Re: [Intel-gfx] [pull] drm-intel-next

[Stéphane Marchesin]

-lkml

On Sun, Mar 17, 2013 at 12:46 PM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Mar 15, 2013 at 3:11 AM, Stéphane Marchesin
 stephane.marche...@gmail.com wrote:
   drm/i915: read out the modeset hw state at load and resume time
 This commit regresses modeset on the samsung series 5 chromebook (it
 is basically a pineview machine with an lvds panel). I don't seem to
 be able to set any mode on it any longer.

 Does that mean the kernel refuses to set the mode, or that you get a
 black screen?


I get a black screen.

 For starters I guess we need:
 - drm.debug=0xe dmesg from just before that commit
 - same for latest 3.9-rc kernels, presuming it's not broken there

 Latest upstream has a minor chance to work better I think since we've
 improved the pfit handling in the setup and teardown sequence a bit.

 Generally lvds has been hitmiss on way too many machines
 unfortunately with things randomly breaking and getting fixed again
 (e.g. one of Chris' machines works again with the new code ...). And
 the commit above doesn't really change much in the code itself but it
 does change the order (and timing) of the different enable/disable
 codepaths.

So I did look at the thing a bit, and it triggers the workaround
if (INTEL_INFO(dev)-gen  4  !intel_check_plane_mapping(crtc)) {
which seems to be part of the problem (but not the whole problem as
removing that gets me a corrupted display, looks like the second pipe
stays enabled then).

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

Re: [Intel-gfx] [pull] drm-intel-next

[Stéphane Marchesin]

On Thu, Sep 13, 2012 at 7:18 AM, Daniel Vetter dan...@ffwll.ch wrote:
 Hi Dave,

 The big ticket item here is the new i915 modeset infrastructure.
 Shockingly it didn't not blow up all over the place (i.e. I've managed to
 fix the ugly issues before merging). 1-2 smaller corner cases broke, but
 we have patches. Also, there's tons of patches on top of this that clean
 out cruft and fix a few bugs that couldn't be fixed with the crtc helper
 based stuff. So more stuff to come ;-)

 Also a few other things:
 - Tiny fix in the fb helper to go through the official dpms interface
   instead of calling the crtc helper code.
 - forcewake code frobbery from Ben, code should be more in-line with
   what Windows does now.
 - fixes for the render ring flush on hsw (Paulo)
 - gpu frequency tracepoint
 - vlv forcewake changes to better align it with our understanding of the
   forcewake magic.
 - a few smaller cleanups

 Cheers, Daniel


 The following changes since commit d7c3b937bdf45f0b844400b7bf6fd3ed50bac604:

   drm/i915: Remove __GFP_NO_KSWAPD (2012-08-27 17:11:38 +0200)

 are available in the git repository at:

   git://people.freedesktop.org/~danvet/drm-intel 
 tags/drm-intel-next-2012-09-09

 for you to fetch changes up to e04190e0ecb236c51af181c18c545ea076fb9cca:

   drm/fb helper: don't call drm_helper_connector_dpms directly (2012-09-08 
 00:51:15 +0200)

 

 Ben Widawsky (5):
   drm/i915: Extract forcewake ack timeout
   drm/i915: use cpu_relax() in wait_for_atomic
   drm/i915: Change forcewake timeout to 2ms
   drm/i915: Never read FORCEWAKE
   drm/i915: Enable some sysfs stuff without CONFIG_PM

 Chris Wilson (1):
   drm/i915: Convert remaining debugfs iterators over rings to 
 for_each_ring()

 Daniel Vetter (66):
   drm/ips: move drps/ips/ilk related variables into dev_priv-ips
   drm/i915: add a tracepoint for gpu frequency changes
   drm/i915: align vlv forcewake with common lore
   drm/i915: differ error message between forcwake timeouts
   drm/i915: add crtc-enable/disable vfuncs insted of dpms
   drm/i915: rip out crtc prepare/commit indirection
   drm/i915: add direct encoder disable/enable infrastructure
   drm/i915/hdmi: convert to encoder-disable/enable
   drm/i915/tv: convert to encoder enable/disable
   drm/i915/lvds: convert to encoder disable/enable
   drm/i915/dp: convert to encoder disable/enable
   drm/i915/crt: convert to encoder disable/enable
   drm/i915/sdvo: convert to encoder disable/enable
   drm/i915/dvo: convert to encoder disable/enable
   drm/i915: convert dpms functions of dvo/sdvo/crt
   drm/i915: rip out encoder-disable/enable checks
   drm/i915: clean up encoder_prepare/commit
   drm/i915: copypaste drm_crtc_helper_set_config
   drm/i915: call set_base directly
   drm/i915: inline intel_best_encoder
   drm/i915: copypaste drm_crtc_helper_set_mode
   drm/i915: simplify intel_crtc_prepare_encoders
   drm/i915: rip out encoder-prepare/commit
   drm/i915: call crtc functions directly
   drm/i915: WARN when trying to enabled an unused crtc
   drm/i915: Add interfaces to read out encoder/connector hw state
   drm/i915/dp: implement get_hw_state
   drm/i915/hdmi: implement get_hw_state
   drm/i915/tv: implement get_hw_state
   drm/i915/lvds: implement get_hw_state
   drm/i915/crt: implement get_hw_state
   drm/i915/sdvo: implement get_hw_state
   drm/i915/dvo: implement get_hw_state
   drm/i915: read out the modeset hw state at load and resume time

Hi Daniel,

This commit regresses modeset on the samsung series 5 chromebook (it
is basically a pineview machine with an lvds panel). I don't seem to
be able to set any mode on it any longer.

Any idea?

Stéphane

   drm/i915: check connector hw/sw state
   drm/i915: rip out intel_crtc-dpms_mode
   drm/i915: rip out intel_dp-dpms_mode
   drm/i915: ensure the force pipe A quirk is actually followed
   drm/i915: introduce struct intel_set_config
   drm/i915: extract modeset config save/restore code
   drm/i915: extract intel_set_config_compute_mode_changes
   drm/i915: extract intel_set_config_update_output_state
   drm/i915: implement crtc helper semantics relied upon by the fb helper
   drm/i915: don't update the fb base if there is no fb
   drm/i915: convert pointless error checks in set_config to BUGs
   drm/i915: don't save all the encoder/crtc state in set_config
   drm/i915: stage modeset output changes
   drm/i915: push crtc-fb update into pipe_set_base
   drm/i915: remove crtc disabling special case
   drm/i915: move output commit and crtc disabling into set_mode
   drm/i915: extract adjusted mode computation
   drm/i915: use staged outuput config in tv-mode_fixup
   drm/i915: use staged outuput config in lvds-mode_fixup
   

Re: [Intel-gfx] [PATCH] drm/i915: Increase the RC6p threshold.

[Stéphane Marchesin]

On Tue, Jan 29, 2013 at 7:41 PM, Stéphane Marchesin marc...@chromium.orgwrote:

 This increases GEN6_RC6p_THRESHOLD from 10 to 15. For some
 reason this avoids the gen6_gt_check_fifodbg.isra warnings and
 associated GPU lockups, which makes my ivy bridge machine stable.


Ping?


 Signed-off-by: Stéphane Marchesin marc...@chromium.org
 ---
  drivers/gpu/drm/i915/intel_pm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/intel_pm.c
 b/drivers/gpu/drm/i915/intel_pm.c
 index 3280cff..dde0ded 100644
 --- a/drivers/gpu/drm/i915/intel_pm.c
 +++ b/drivers/gpu/drm/i915/intel_pm.c
 @@ -2572,7 +2572,7 @@ static void gen6_enable_rps(struct drm_device *dev)
 I915_WRITE(GEN6_RC_SLEEP, 0);
 I915_WRITE(GEN6_RC1e_THRESHOLD, 1000);
 I915_WRITE(GEN6_RC6_THRESHOLD, 5);
 -   I915_WRITE(GEN6_RC6p_THRESHOLD, 10);
 +   I915_WRITE(GEN6_RC6p_THRESHOLD, 15);
 I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */

 /* Check if we are enabling RC6 */
 --
 1.8.1


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

[Intel-gfx] [PATCH] drm/i915: Increase the RC6p threshold.

[Stéphane Marchesin]

This increases GEN6_RC6p_THRESHOLD from 10 to 15. For some
reason this avoids the gen6_gt_check_fifodbg.isra warnings and
associated GPU lockups, which makes my ivy bridge machine stable.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3280cff..dde0ded 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2572,7 +2572,7 @@ static void gen6_enable_rps(struct drm_device *dev)
I915_WRITE(GEN6_RC_SLEEP, 0);
I915_WRITE(GEN6_RC1e_THRESHOLD, 1000);
I915_WRITE(GEN6_RC6_THRESHOLD, 5);
-   I915_WRITE(GEN6_RC6p_THRESHOLD, 10);
+   I915_WRITE(GEN6_RC6p_THRESHOLD, 15);
I915_WRITE(GEN6_RC6pp_THRESHOLD, 64000); /* unused */
 
/* Check if we are enabling RC6 */
-- 
1.8.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Ajdust down threshold in intel_pm.

[Stéphane Marchesin]

On Mon, Jul 16, 2012 at 12:50 PM, Daniel Vetter dan...@ffwll.ch wrote:

 On Wed, Jul 04, 2012 at 09:52:11AM +0200, Daniel Vetter wrote:
  On Tue, Jul 03, 2012 at 02:16:42PM -0700, Stéphane Marchesin wrote:
   The up and down thresholds are very asymetric, so it is possible
   to have a case where a spike of rendering increases the GPU clock to
   the max (because the up threshold is low) and then a simple blinking
   cursor is enough to keep the clock at the maximum speed forever
   (because the down threshold is high).
  
   Lowering the down threshold allows the GPU clock to go back down even
   when there is a blinking cursor on the screen.
  
   Signed-off-by: Stéphane Marchesin marc...@chromium.org
 
  I've just merged Eugeni's hsw rc6 patches - those contain newly tuning
  variables. Can you maybe try out whether these would have the same
 effect?
  I'd prefer to simple enable these, presuming that the hw guys we've got
  them from did some decent tuning ...

 Ping.

 3.6 merge window is approach fast and I think I'd be good to get this in
 ... Or something similar, based on the hsw ratio between downclock and
 upclock limit, but with the slightly bigger thresholds used by ivb/snb for
 upclocks maybe?


So now that the dust settled, and that we better understand what's going
on, I am sure that those values are not adequate for us (neither the
default SNB/IVB, nor the Haswell ones).

For the record, here is what we set differently for Chrome OS to solve our
issues (we didn't see a performance regression, but we do get a major power
consumption reduction for lighter GPU loads like playing a video and that
blinking cursor):

GEN6_RP_DOWN_TIMEOUT 1
GEN6_RP_UP_THRESHOLD 0x4000
GEN6_RP_DOWN_THRESHOLD 0x4000

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

[Intel-gfx] [PATCH] drm/i915: Make intel_panel_get_backlight static.

[Stéphane Marchesin]

This function isn't used outside of intel_panel.c, so make it static.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_drv.h   |1 -
 drivers/gpu/drm/i915/intel_panel.c |2 +-
 2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8435355..3afe355 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -380,7 +380,6 @@ extern void intel_pch_panel_fitting(struct drm_device *dev,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
 extern u32 intel_panel_get_max_backlight(struct drm_device *dev);
-extern u32 intel_panel_get_backlight(struct drm_device *dev);
 extern void intel_panel_set_backlight(struct drm_device *dev, u32 level);
 extern int intel_panel_setup_backlight(struct drm_device *dev);
 extern void intel_panel_enable_backlight(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 10c7d39..9474488 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -213,7 +213,7 @@ static u32 intel_panel_compute_brightness(struct drm_device 
*dev, u32 val)
return val;
 }
 
-u32 intel_panel_get_backlight(struct drm_device *dev)
+static u32 intel_panel_get_backlight(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
u32 val;
-- 
1.7.5.3.367.ga9930

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

[Intel-gfx] [PATCH] drm/i915: Ajdust down threshold in intel_pm.

[Stéphane Marchesin]

The up and down thresholds are very asymetric, so it is possible
to have a case where a spike of rendering increases the GPU clock to
the max (because the up threshold is low) and then a simple blinking
cursor is enough to keep the clock at the maximum speed forever
(because the down threshold is high).

Lowering the down threshold allows the GPU clock to go back down even
when there is a blinking cursor on the screen.

Signed-off-by: Stéphane Marchesin marc...@chromium.org
---
 drivers/gpu/drm/i915/intel_pm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d0ce2a5..eba882a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2432,7 +2432,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv)
   dev_priv-max_delay  24 |
   dev_priv-min_delay  16);
I915_WRITE(GEN6_RP_UP_THRESHOLD, 1);
-   I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 100);
+   I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 10);
I915_WRITE(GEN6_RP_UP_EI, 10);
I915_WRITE(GEN6_RP_DOWN_EI, 500);
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
-- 
1.7.5.3.367.ga9930

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

Re: [Intel-gfx] GMA 950 Intel 945G gallium driver

[Stéphane Marchesin]

On Sun, Jun 3, 2012 at 5:44 AM, Emam Hossain imamdxl8...@gmail.com wrote:

 Hello Everyone,

 Recently I have tested one of my old desktop which got Intel 945G on a
 Dual Core CPU. I have installed Ubuntu 11.10 with XServer 1.11, kernel 3.2
 and xf86-video-intel 2.18.

 What I have found that Gallium driver i915g from Mesa 7.11 and 8 is
 performing better than officially supported DRI i915 driver.

 For example, when tested against the following games:

 BEEP, http://www.desura.com/games/beep (gallium plays fine while dri not)
 BIT.TRIP.RUNNER from humble bundle,
 http://bittripgame.com/bittrip-runner.html  (gallium smooth gameplay, dri
 slow)
 and many more.

 Moreover, Windows games with WINE are not playable at all or broken with
 DRI driver while runs good with gallium. For example with games:

 Need for Speed Underground
 Flatout 1
 Need for Speed Most Wanted

 gallium does the job while DRI does not.

 So, my question is why dont support gallium driver when it is performing
 better than DRI driver. why not make gallium driver better since Intel 945G
 does not have hardware support for many features, DRI driver is just slow
 for modern games except GL 1.1 games while gallium driver making use of CPU
 to perform those missing hardware features and making games at least run.
 Moreover, Windows driver does similar approach like gallium 3D.


I feel that the reason is that the classic i915 driver is in maintenance
mode and focus is on newer GPUs. The gallium i915 driver is what we use on
some Chrome OS machines, and that's the main reason I've been working on it.

With that said, I'm pondering exposing GL 2.1 on it, since it seems legit
per the spec to hack sRGB texture support with U8 + fragment shader
instructions. That'd allow some unigine-based games to run.

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

Re: [Intel-gfx] GMA 950 Intel 945G gallium driver

[Stéphane Marchesin]

On Fri, Jun 22, 2012 at 12:41 PM, Alan W. Irwin
ir...@beluga.phys.uvic.cawrote:

 On 2012-06-22 11:18-0700 Stéphane Marchesin wrote:



 On Sun, Jun 3, 2012 at 5:44 AM, Emam Hossain imamdxl8...@gmail.com
 wrote:
  Hello Everyone,

  Recently I have tested one of my old desktop which got Intel 945G on
 a Dual Core CPU. I have installed Ubuntu 11.10 with
  XServer 1.11, kernel 3.2 and xf86-video-intel 2.18.

  What I have found that Gallium driver i915g from Mesa 7.11 and 8 is
 performing better than officially supported DRI i915
  driver.

  For example, when tested against the following games:

  BEEP, 
 http://www.desura.com/games/**beephttp://www.desura.com/games/beep(gallium 
 plays fine while dri not)
  BIT.TRIP.RUNNER from humble bundle, http://bittripgame.com/**
 bittrip-runner.html http://bittripgame.com/bittrip-runner.html
 (gallium smooth gameplay, dri slow)
  and many more.

  Moreover, Windows games with WINE are not playable at all or broken
 with DRI driver while runs good with gallium. For example
  with games:

  Need for Speed Underground
  Flatout 1
  Need for Speed Most Wanted

  gallium does the job while DRI does not.

  So, my question is why dont support gallium driver when it is
 performing better than DRI driver. why not make gallium driver
  better since Intel 945G does not have hardware support for many
 features, DRI driver is just slow for modern games except GL
  1.1 games while gallium driver making use of CPU to perform those
 missing hardware features and making games at least run.
  Moreover, Windows driver does similar approach like gallium 3D.


 I feel that the reason is that the classic i915 driver is in maintenance
 mode and focus is on newer GPUs. The gallium i915 driver is what
 we use on some Chrome OS machines, and that's the main reason I've been
 working on it.

 With that said, I'm pondering exposing GL 2.1 on it, since it seems legit
 per the spec to hack sRGB texture support with U8 + fragment
 shader instructions. That'd allow some unigine-based games to run.


 The i915g driver sounds like an interesting alternative for driving
 older Intel equipment.  For example, one of my computers (which I am
 using as a thin client/X terminal) is an ASUS Eee netbook with the
 945GME chipset.  The Debian stable version of the classic driver works
 okay on that.  For example, I can run env LIBGL_ALWAYS_INDIRECT=1
 foobillard on our principal machine and display the results on the
 thin client without obvious issues.  However, that is a pretty old
 version of X, and there have been numerous changes to the Intel
 graphics stack since then without much official testing on old
 equipment (or on thin clients for that matter) by the Intel software
 team.  Therefore, I am not too sure whether the newer version of the
 Intel graphics stack will work well on that equipment when I upgrade
 to Debian testing, and the original post in this thread (quoted above)
 isn't exactly reassuring on that issue.

 Therefore, I would like to try out the i915g driver myself. Are there
 build instructions somewhere for that driver


You just need to download mesa (preferably 8.x) and:
./configure --with-gallium-drivers=i915
make
make install

That should do the trick :)



 or better yet is there a
 Debian (or Ubuntu) package that includes it?


I don't think there is a debian/ubuntu package, but I could be wrong.

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

[Intel-gfx] [PATCH] CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB

[Stéphane Marchesin]

From: Duncan Laurie dlau...@chromium.org

This is the method used to override LVDS in intel_lvds and appears to be
an effective way to ensure that the driver does not enable VGA hotplug.

This is the same patch from 2.6.32 kernel in R12 but ported to 2.6.38,
will send upstream next.

Signed-off-by: Duncan Laurie dlau...@chromium.org

BUG=chrome-os-partner:117
TEST=Check PORT_HOTPLUG_EN to see if hotplug interrupt is disabled.
Run the following command as root, specifically looking at bit 9:
mmio_read32 $[$(pci_read32 0 2 0 0x10) + 0x61110] = 0x

Change-Id: Id8240f9fb31d058d8d79ee72f7b4615c43893f5a
Reviewed-on: http://gerrit.chromium.org/gerrit/1390
Reviewed-by: Olof Johansson ol...@chromium.org
Tested-by: Duncan Laurie dlau...@chromium.org
---
 drivers/gpu/drm/i915/intel_crt.c |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 0979d88..c1ecbfd 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -24,6 +24,7 @@
  * Eric Anholt e...@anholt.net
  */
 
+#include linux/dmi.h
 #include linux/i2c.h
 #include linux/slab.h
 #include drmP.h
@@ -544,6 +545,24 @@ static const struct drm_encoder_funcs intel_crt_enc_funcs 
= {
.destroy = intel_encoder_destroy,
 };
 
+static int __init intel_no_crt_dmi_callback(const struct dmi_system_id *id)
+{
+   DRM_DEBUG_KMS(Skipping CRT initialization for %s\n, id-ident);
+   return 1;
+}
+
+static const struct dmi_system_id intel_no_crt[] = {
+   {
+   .callback = intel_no_crt_dmi_callback,
+   .ident = ACER ZGB,
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, ACER),
+   DMI_MATCH(DMI_PRODUCT_NAME, ZGB),
+   },
+   },
+   { }
+};
+
 void intel_crt_init(struct drm_device *dev)
 {
struct drm_connector *connector;
@@ -551,6 +570,10 @@ void intel_crt_init(struct drm_device *dev)
struct intel_connector *intel_connector;
struct drm_i915_private *dev_priv = dev-dev_private;
 
+   /* Skip machines without VGA that falsely report hotplug events */
+   if (dmi_check_system(intel_no_crt))
+   return;
+
crt = kzalloc(sizeof(struct intel_crt), GFP_KERNEL);
if (!crt)
return;
-- 
1.7.5.3.367.ga9930

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

[Intel-gfx] [PATCH] Properly decrement flip_count if we want to undo.

[Stéphane Marchesin]

---
 src/intel_display.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/intel_display.c b/src/intel_display.c
index b55b110..c9fdc59 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -1499,6 +1499,9 @@ intel_do_pageflip(intel_screen_private *intel,
 error_undo:
drmModeRmFB(mode-fd, mode-fb_id);
mode-fb_id = old_fb_id;
+   for (i = 0; i  config-num_crtc; i++)
+   if (config-crtc[i]-enabled)
+   mode-flip_count--;
 
 error_out:
xf86DrvMsg(scrn-scrnIndex, X_WARNING, Page flip failed: %s\n,
-- 
1.7.5.3.367.ga9930

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