Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly
On Wed, May 04, 2016 at 08:32:17AM +0100, Lee Jones wrote:
> On Mon, 02 May 2016, Daniel Vetter wrote:
>
> > On Fri, Apr 29, 2016 at 11:31:44AM +0200, Linus Walleij wrote:
> > > On Fri, Apr 22, 2016 at 9:38 PM, wrote:
> > >
> > > > From: Ville Syrjälä
> > > >
> > > > GPIO lookup tables are supposed to be zero terminated. Let's do that
> > > > and avoid accidentally walking off the end.
> > > >
> > > > Cc: Shobhit Kumar
> > > > Cc: Samuel Ortiz
> > > > Cc: Linus Walleij
> > > > Cc: Alexandre Courbot
> > > > Cc: Thierry Reding
> > > > Cc: Lee Jones
> > > > Cc: sta...@vger.kernel.org
> > > > Fixes: 61dd2ca2d44e ("mfd: intel_soc_pmic_core: Add lookup table for
> > > > Panel Control as GPIO signal")
> > > > Signed-off-by: Ville Syrjälä
> > >
> > > Acked-by: Linus Walleij
> >
> > Applied to drm-intel trees, thanks for patch, reviews&acks.
>
> Do what now? How can you apply a patch for a subsystem you don't have
> responsibility for? This is bound to cause merge conflicts.
Oh crap, I thought Linus' ack was for the mfd stuff and didn't bother
double-checking with MAINTAINTERS. Should I throw it out again and you'll
pick it up, or ok as such?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL. (v2)
On Wed, May 04, 2016 at 02:49:50PM +0100, Lionel Landwerlin wrote: > On 20/04/16 13:38, Daniel Vetter wrote: > >On Wed, Apr 20, 2016 at 09:00:09AM +0200, Maarten Lankhorst wrote: > >>Op 19-04-16 om 12:13 schreef Lionel Landwerlin: > >>>On 19/04/16 07:02, Maarten Lankhorst wrote: > Op 18-04-16 om 18:47 schreef Bob Paauwe: > >The i915 driver is now using atomic properties and atomic commit > >to handle the legacy set gamma IOCTL. However, if the driver is > >configured without atomic (nuclear_pageflip = false), it won't > >update the legacy properties for degamma_lut, gamma_lut and ctm > >leaving them out of sync with the atomic version of the properties. > > > >Until the driver is full atomic, make sure we update the non-atomic > >version of the properties. > > > >v2: Update the comment with a FIXME. (Daniel) > > > Seems to me that this is fixed by [PATCH] drm: atomic: fix legacy gamma > set helper? > Not sure why this patch is required on top. > > >>>Daniel would prefer to have this fix only in the i915 driver as this is > >>>the last driver still transitioning to atomic. > >>> > >>Oh indeed, lack of DRIVER_ATOMIC cap again. :( > >>Still feels like something that doesn't belong in the driver, but ok.. > >Agreed, hence why I asked for a FIXME comment so we don't forget to rip > >this out once we enale DRIVER_ATOMIC for real. > >-Daniel > Hi Daniel, > > Was there anything missing in the last version of this patch? Pending review comments from Maarten, and no r-b tag. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change
On Fri, May 06, 2016 at 05:39:56PM -0400, Lyude wrote:
> If an MST device is disconnected while the machine is suspended, the
> number of connectors will change as well after we call
> intel_dp_mst_resume(). This means that any previous atomic state we had
> before suspending is no longer valid, since it'll still be pointing to
> missing connectors. We need to check for this before committing the
> state, otherwise we'll kernel panic on resume whenever if any MST
> display was disconnected before we started resuming:
>
> BUG: unable to handle kernel NULL pointer dereference at 0008
> IP: [] drm_atomic_helper_check_modeset+0x29f/0xb40
> [drm_kms_helper]
> Call Trace:
> [] intel_atomic_check+0x34/0x1180 [i915]
> [] ? mark_held_locks+0x6f/0xa0
> [] ? trace_hardirqs_on_caller+0x129/0x1b0
> [] drm_atomic_check_only+0x192/0x620 [drm]
> [] ? pci_pm_thaw+0x21/0x90
> [] drm_atomic_commit+0x17/0x60 [drm]
> [] intel_display_resume+0xbd/0x160 [i915]
> [] ? pci_pm_thaw+0x90/0x90
> [] i915_drm_resume+0xd8/0x160 [i915]
> [] i915_pm_resume+0x25/0x30 [i915]
> [] pci_pm_resume+0x64/0xa0
> [] dpm_run_callback+0x90/0x190
> [] device_resume+0xd5/0x1f0
> [] async_resume+0x1d/0x50
> [] async_run_entry_fn+0x48/0x150
> [] process_one_work+0x1e9/0x5c0
> [] ? process_one_work+0x166/0x5c0
> [] worker_thread+0x48/0x4e0
> [] ? process_one_work+0x5c0/0x5c0
> [] kthread+0xe4/0x100
> [] ret_from_fork+0x22/0x50
> [] ? kthread_create_on_node+0x200/0x200
>
> Changes since v1:
> - Move drm_atomic_state_free() call down so we're holding the
> appropriate locks when destroying the atomic state
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lyude
Is this still an issue on -nightly with the connector refcounting fixed?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0f29ef6..d68efc7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15934,6 +15934,18 @@ void intel_display_resume(struct drm_device *dev)
> retry:
> ret = drm_modeset_lock_all_ctx(dev, &ctx);
>
> + /*
> + * With MST, the number of connectors can change between suspend and
> + * resume, which means that the state we want to restore might now be
> + * impossible to use since it'll be pointing to non-existant
> + * connectors.
> + */
> + if (ret == 0 &&
> + state->num_connector != dev->mode_config.num_connector) {
> + drm_atomic_state_free(state);
> + state = NULL;
> + }
> +
> if (ret == 0 && !setup) {
> setup = true;
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Friday, April 29, 2016 8:15 PM
> To: Kannan, Vandana
> Cc: intel-gfx@lists.freedesktop.org; Smith, Gary K
>
> Subject: Re: [PATCH v2 2/2] drm/i915: Render decompression support for
> Gen9 and above
>
> On Fri, Apr 29, 2016 at 08:27:00PM +0530, Vandana Kannan wrote:
> > This patch includes enabling render decompression (RC) after checking
> > all the requirements (format, tiling, rotation etc.).
> >
> > TODO:
> > 1. Disable stereo 3D when render decomp is enabled (bit 7:6) 2. Render
> > decompression must not be used in VTd pass-through mode 3. Program
> > hashing select CHICKEN_MISC1 bit 15 4. For Gen10, add support for RGB
> > 1010102 5. RC-FBC workaround 6. RC watermark calculation
> >
> > The reason for using a plane property instead of fb modifier:- In
> > Android, OGL passes a render compressed buffer to hardware composer
> > (HWC), which would then request a flip on that buffer after checking
> > if the target can support render compressed buffer. For example, only
> > planes
> > 1 and 2 on pipes 1 and 2 can support RC. In case the target cannot
> > support it, HWC will revert back to OGL requesting for uncompressed
> > buffer.
> > Here,
> > if plane property is used, OGL would send back the buffer (same ID)
> > after decompression, marked uncompressed. If fb modifier was used, a
> > different version of the buffer would have to be maintained for
> > different combinations - in the simple case of render compressed vs
> > uncompressed buffer, there would be 2 fbs with 2 IDs. So, in this
> > case, OGL would give a reference to a fb with a different ID.
> > To avoid the difficulty of keeping track of multiple fbs and the
> > subsequent complexity in debug, the architecture forum decided to go
> > ahead with a plane property for RC.
> >
> > [Mayuresh] Added the plane check in skl_check_compression()
> >
> > v2: Ville's review comments addressed
> > - Removed WAs specific to SKL-C and BXT-A
> > - Assign capabilities according to pipe and plane during property
> > creation
> > - in skl_check_compression(), check for conditions that must be
> > satisifed
> >
> > Maintaining the check for pixel format, even though compressed fb of
> > format other RGB should not have been created, to be on the safer
> side.
> > Added checks for BGR too.
> > Bitmask is being used for the property to accommodate 2 more options
> > expected to be added in future.
> >
> > This patch depends on Ville's patch series on fb->offsets.
> > (Ref: git://github.com/vsyrjala/linux.git fb_offsets_14)
> >
> > Testing is in progress for v2 of the patch.
> >
> > Signed-off-by: Vandana Kannan
> > Cc: Ville Syrjälä
> > Cc: Smith, Gary K
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_reg.h | 22 +
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 24 +-
> > drivers/gpu/drm/i915/intel_display.c | 135
> +-
> > drivers/gpu/drm/i915/intel_drv.h | 10 +++
> > drivers/gpu/drm/i915/intel_sprite.c | 27 +-
> > 6 files changed, 213 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 32f0597..ba32e7c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1901,6 +1901,7 @@ struct drm_i915_private {
> >
> > struct drm_property *broadcast_rgb_property;
> > struct drm_property *force_audio_property;
> > + struct drm_property *render_comp_property;
> >
> > /* hda/i915 audio component */
> > struct i915_audio_component *audio_component; diff --git
> > a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index 25e229b..da45cc9 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5816,6 +5816,28 @@ enum skl_disp_power_wells {
> > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \
> > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B))
> >
> > +#define PLANE_AUX_DIST_1_A 0x701c0
> > +#define PLANE_AUX_DIST_2_A 0x702c0
> > +#define PLANE_AUX_DIST_1_B 0x711c0
> > +#define PLANE_AUX_DIST_2_B 0x712c0
> > +#define _PLANE_AUX_DIST_1(pipe) \
> > + _PIPE(pipe, PLANE_AUX_DIST_1_A,
> PLANE_AUX_DIST_1_B) #define
> > +_PLANE_AUX_DIST_2(pipe) \
> > + _PIPE(pipe, PLANE_AUX_DIST_2_A,
> PLANE_AUX_DIST_2_B)
> > +#define PLANE_AUX_DIST(pipe, plane) \
> > + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe),
> _PLANE_AUX_DIST_2(pipe))
> > +
> > +#define PLANE_AUX_OFFSET_1_A 0x701c4
> > +#define PLANE_AUX_OFFSET_2_A 0x702c4
> > +#define PLANE_AUX_OFFSET_1_B 0x711c4
> > +#define PLANE_AUX_OFFSET_2_B 0x712c4
> > +#define _PLANE_AUX_OFFSET_1(pipe) \
> > + _PIPE(pipe, PLANE_AUX_OFFSET_1_A,
> PLANE_A
Re: [Intel-gfx] [PATCH 15/16] drm/i915: Mechanism to forward clock monotonic time in perf samples
On Sat, 2016-04-23 at 01:19 +0530, Chris Wilson wrote:
> On Fri, Apr 22, 2016 at 05:04:04PM +0530, sourab.gu...@intel.com wrote:
> > +static u64 get_current_gpu_ts(struct drm_i915_private *dev_priv)
> > +{
> > + return ((u64)I915_READ(GT_TIMESTAMP_COUNT_UDW) << 32) |
> > + I915_READ(GT_TIMESTAMP_COUNT);
>
> return I915_READ64_2x32(GT_TIMESTAMP_COUNT, GT_TIMESTAMP_COUNT_UDW);
Thanks for pointing out. Will make this change.
>
> > +static void i915_perf_get_clock(struct drm_i915_private *dev_priv,
> > + u64 *clk_mono, u64 *gpu_time, u64 *gpu_ts)
> > +{
> > + u64 remainder, ts_interval = NSEC_PER_SEC;
> > + u32 gpu_freq = dev_priv->perf.timestamp_frequency;
> > + unsigned long flags;
> > +
> > + local_irq_save(flags);
> > + *clk_mono = ktime_get_mono_fast_ns();
> > + *gpu_ts = get_current_gpu_ts(dev_priv);
> > + local_irq_restore(flags);
> > +
> > + remainder = do_div(ts_interval, gpu_freq);
> > + remainder *= *gpu_ts;
> > + do_div(remainder, gpu_freq);
> > +
> > + *gpu_time = ((*gpu_ts) * ts_interval) + remainder;
> > +}
> > +
> > +static void i915_perf_clock_sync_work(struct work_struct *work)
> > +{
>
> Have you looked at cross-timestamps?
I was looking at the cross-timestamp patch set
(https://lkml.org/lkml/2016/1/4/541), but I'm not entirely sure the
cross timestamp stuff is solving the same problem. The cross timestamp
stuff is trying to "synchronously capture system/device timestamp(s)".
While here, we have a log of many recorded device timestamps and want to
correlate all of those with system timestamp (_CLOCK_MONOTONOC for now).
As we aren't reading system/device timestamps together for all
timestamps we have, our problem is more about deriving an accurate idea
of timestamp frequency to improve the accuracy when correlating between
the synchronization points. Maybe the cross timestamp stuff will help to
periodically read tightly correlated timestamp pairs synchronously which
can be used as basis for correlating the logged timestamps based on our
derived timestamp frequency. This idea can be evaluated once the cross
timestamp patches land in kernel.
> -Chris
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [Regression report] Weekly regression report WW19
WW19 Regression report. There was no new regressions last week. Previous Regressions +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 72782 | [945GM bisected] screen blank on S3 resume on | 2013-12-17 | Yes| | 84855 | [ILK regression]igt kms_rotation_crc/sprite-r | 2014-10-10 | No | | 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | No | | 87725 | [BDW Bisected] OglBatch7 performance reduced | 2014-12-26 | Yes| | 87726 | [BDW Bisected] OglDrvCtx performance reduced | 2014-12-26 | Yes| | 88439 | [BDW Bisected]igt/gem_reloc_vs_gpu/forked-fau | 2015-01-15 | Yes| | 89334 | [945 regression] 4.0-rc1 kernel GPU hang: ec | 2015-02-26 | No | | 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | No | | 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | No | | 89728 | [HSW/BDW/BYT bisected] igt / pm_rps / reset f | 2015-03-23 | Yes| | 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | Yes| | 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | Yes| | 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | Yes| | 90368 | [SNB BSW SKL BXT KBL] bisected igt/kms_3d has | 2015-05-08 | Yes| | 90732 | [BDW/BSW Bisected]igt/gem_reloc_vs_gpu/forked | 2015-05-29 | Yes| | 91959 | [865g Linux regression] GPU hang and disabled | 2015-09-10 | No | | 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | Yes| | 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | No | | 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 | No | | 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will | 2015-10-10 | Yes| | 92502 | [SKL] [Regression] igt/kms_flip/2x-flip-vs-ex | 2015-10-16 | No | | 92575 | [4.2 regression] Massive graphics corruption | 2015-10-21 | No | | 92972 | Black screen on Intel NUC hardware (i915) pos | 2015-11-16 | No | | 93122 | [SNB BAT IGT regression] pm_rpm started skipp | 2015-11-26 | No | | 93263 | 945GM regression since 4.3| 2015-12-05 | No | | 93393 | Regression for Skylake modesetting in kernel | 2015-12-16 | No | | 93802 | [IVB bisected] switching to tty1 causes fifo | 2016-01-20 | Yes| | 93971 | video framerate performance regression with U | 2016-02-02 | No | | 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 | No | | 94416 | [KBL HSW] [Regression] kms_frontbuffer_tracki | 2016-03-06 | No | | 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 | No | | 94585 | [BXT-P/KBL/BSW] igt/gem_reset_stats regressio | 2016-03-17 | No | | 94587 | [KBL] igt/kms_plane/plane-panning-bottom-righ | 2016-03-17 | No | | 94588 | [KBL/BSW/BXT] igt/gem_reloc_overflow regressi | 2016-03-17 | No | | 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend regressio | 2016-03-17 | No | | 94676 | Possible kernel regression for gen3 and earli | 2016-03-23 | No | | 94748 | Black screen on Skylake (mouse position relat | 2016-03-29 | No | | 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 | No | | 95172 | [KBL] [regression] pm_rpm / debugfs-read fail | 2016-04-27 | No | | 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 | No | +---+---+++ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/drm-misc
Hi Dave, Refcounting is hard, so here's a quick pull request with the one-liner to fix up i915. Otherwise just a few other small things I picked up. Plus the regression fix from Marten for rmfb behaviour that lingered around forever since no testers. Feel free to cherry-pick that over to drm-fixes, but given that there's not many who seemed to have cared, meh. Cheers, Daniel The following changes since commit 0552f7651bc233e5407ab06ba97a9d7c25e19580: drm/i915/mst: use reference counted connectors. (v3) (2016-05-05 12:52:07 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-05-08 for you to fetch changes up to 8863dc7f5642737e49ff681cbb842d2c614bdcf4: drm/i915: Correctly refcount connectors in hw state readou (2016-05-06 16:09:12 +0200) Daniel Vetter (3): drm: Fix up markup fumble drm: Add gpu.tmpl docbook to MAINTAINERS entry drm/i915: Correctly refcount connectors in hw state readou Lyude (1): drm/fb_helper: Fix a few typos Maarten Lankhorst (1): drm/core: Do not preserve framebuffer on rmfb, v4. Thierry Reding (1): drm/panel: Flesh out kerneldoc Documentation/DocBook/gpu.tmpl | 12 -- MAINTAINERS | 1 + drivers/gpu/drm/drm_crtc.c | 63 drivers/gpu/drm/drm_fb_helper.c | 6 +-- drivers/gpu/drm/drm_panel.c | 61 +++ drivers/gpu/drm/i915/intel_display.c | 5 +++ include/drm/drm_modeset_helper_vtables.h | 2 +- include/drm/drm_panel.h | 59 ++ 8 files changed, 195 insertions(+), 14 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Updated drm-intel-testing
Hi all, New -testing cycle with cool stuff: - refactor stolen quirks to share code between early quirks and i915 (Joonas) - refactor gem BO/vma funcstion (Tvrtko&Dave) - backlight over DPCD support (Yetunde Abedisi) - more dsi panel sequence support (Jani) - lots of refactoring around handling iomaps, vma, ring access and related topics culmulating in removing the duplicated request tracking in the execlist code (Chris & Tvrtko) includes a small patch for core iomapping code - hw state readout for bxt dsi (Ramalingam C) - cdclk cleanups (Ville) - dedupe chv pll code a bit (Ander) - enable semaphores on gen8+ for legacy submission, to be able to have a direct comparison against execlist on the same platform (Chris) Not meant to be used for anything else but performance tuning - lvds border bit hw state checker fix (Jani) - rpm vs. shrinker/oom-notifier fixes (Praveen Paneri) - l3 tuning (Imre) - revert mst dp audio, it's totally non-functional and crash-y (Lyude) - first official dmc for kbl (Rodrigo) - and tons of small things all over as usual Happy testing! Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)
On Tue, Apr 26, 2016 at 12:25:18PM +0100, Yetunde Adebisi wrote:
> This patch adds support for eDP backlight control using DPCD registers to
> backlight hooks in intel_panel.
>
> It checks for backlight control over AUX channel capability and sets up
> function pointers to get and set the backlight brightness level if
> supported.
>
> v2: Moved backlight functions from intel_dp.c into a new file
> intel_dp_aux_backlight.c. Also moved reading of eDP display control
> registers to intel_dp_get_dpcd
>
> v3: Correct some formatting mistakes
>
> v4: Updated to use AUX backlight control if PWM control is not possible
> (Jani)
> v5: Moved call to initialize backlight registers to dp_aux_setup_backlight
> v6: Check DP_EDP_BACKLIGHT_PIN_ENABLE_CAP is disabled before setting up AUX
> backlight control. To fix BLM_PWM_ENABLE igt test warnings on bdw_ultra
> v7: Add enable_dpcd_backlight module parameter.
> v8: Rebase onto latest drm-intel-nightly branch
> v9: Remove references to intel_dp_dpcd_read_wake
> Split addition edp_dpcd variable into a separate patch
>
> Cc: Bob Paauwe
> Cc: Jani Nikula
> Signed-off-by: Yetunde Adebisi
Just a quick comment since I'm typing the regular changelog summaries: I
think the backlight driver in here would have been real nice as a generic
thing on top of the dp aux library. But ok if the next person gets to do
that, too ;-)
-Daniel
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_params.c| 4 +
> drivers/gpu/drm/i915/i915_params.h| 1 +
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 173
> ++
> drivers/gpu/drm/i915/intel_drv.h | 3 +
> drivers/gpu/drm/i915/intel_panel.c| 4 +
> 6 files changed, 186 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0b88ba0..723c502 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -81,6 +81,7 @@ i915-y += dvo_ch7017.o \
> dvo_tfp410.o \
> intel_crt.o \
> intel_ddi.o \
> + intel_dp_aux_backlight.o \
> intel_dp_link_training.o \
> intel_dp_mst.o \
> intel_dp.o \
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 1779f02..383c076 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -58,6 +58,7 @@ struct i915_params i915 __read_mostly = {
> .guc_log_level = -1,
> .enable_dp_mst = true,
> .inject_load_failure = 0,
> + .enable_dpcd_backlight = false,
> };
>
> module_param_named(modeset, i915.modeset, int, 0400);
> @@ -210,3 +211,6 @@ MODULE_PARM_DESC(enable_dp_mst,
> module_param_named_unsafe(inject_load_failure, i915.inject_load_failure,
> uint, 0400);
> MODULE_PARM_DESC(inject_load_failure,
> "Force an error after a number of failure check points (0:disabled
> (default), N:force failure at the Nth failure check point)");
> +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
> 0600);
> +MODULE_PARM_DESC(enable_dpcd_backlight,
> + "Enable support for DPCD backlight control (default:false)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 02bc278..65e73dd 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -61,6 +61,7 @@ struct i915_params {
> bool verbose_state_checks;
> bool nuclear_pageflip;
> bool enable_dp_mst;
> + bool enable_dpcd_backlight;
> };
>
> extern struct i915_params i915 __read_mostly;
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> new file mode 100644
> index 000..984fb0d
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -0,0 +1,173 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR
Re: [Intel-gfx] [PATCH] drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms
On Sat, May 07, 2016 at 09:18:24PM +0300, Ville Syrjälä wrote:
> On Fri, May 06, 2016 at 09:22:49PM +0100, Chris Wilson wrote:
> > On Fri, May 06, 2016 at 09:35:55PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > @@ -730,9 +730,14 @@ int i915_suspend_switcheroo(struct drm_device *dev,
> > > pm_message_t state)
> > > static int i915_drm_resume(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > + int ret;
> > >
> > > disable_rpm_wakeref_asserts(dev_priv);
> > >
> > > + ret = i915_ggtt_enable_hw(dev);
> > > + if (ret)
> > > + DRM_ERROR("failed to re-enable GGTT\n");
> >
> > Would it not be fatal for resume as well? Failure means we can't use the
> > GGTT, so all subsequent writes will be going into a random address.
>
> Yeah, I assume things would blow up. The question is however, what can
> we do in this case? We'd basically have to shut the entire driver down.
> I don't think we have a way to do that?
No, I was naively thinking that erring out during resume would magically
shut the driver down.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"
On May 08 Stefan Richter wrote: > On May 06 Daniel Vetter wrote: > > On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote: > [...] > > > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s) > > > > This one failed in both runs. Can you please retest with just that using > > > > # kms_frontbuffer_tracking --run-subtest > > fbc-1p-primscrn-spr-indfb-fullscreen > > > > Also please boot with drm.debug=0xe and grab the full dmesg of just that > > single subtest. There's definitely something going wrong here. > > I performed this test with > - plain v4.6-rc6, > - v4.6-rc6 patched with drm-intel-nightly (2016y-05m-06d-14h-29m-58s). > > On v4.6-rc6, the test failed thus: [...] > On v4.6-rc6 plus drm-intel-nightly, the test apparently passed: [...] > I will send the kernel messages from each of these two tests in a reply to > intel-gfx@lists.freedesktop.org only. Attached are the kernel logs from the two test runs. Do you need to see the kernel messages from before the test started too? -- Stefan Richter -==- -=-= -=--- http://arcgraph.de/sr/ [0.00] Linux version 4.6.0-rc6 (stefan@kant) (gcc version 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5) ) #2 SMP PREEMPT Fri May 6 00:25:46 CEST 2016 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.6.0-rc6 root=/dev/sda4 ro rootflags=subvol=@ drm.debug=0xe # ... [ 358.434393] kms_frontbuffer_tracking: executing [ 358.436374] [drm:i915_gem_open] [ 358.436656] [drm:i915_gem_open] [ 358.436669] [drm:drm_mode_getresources] CRTC[3] CONNECTORS[6] ENCODERS[10] [ 358.436672] [drm:drm_mode_getresources] [CRTC:26:crtc-0] [ 358.436673] [drm:drm_mode_getresources] [CRTC:30:crtc-1] [ 358.436674] [drm:drm_mode_getresources] [CRTC:34:crtc-2] [ 358.436675] [drm:drm_mode_getresources] [ENCODER:37:DAC-37] [ 358.436676] [drm:drm_mode_getresources] [ENCODER:38:TMDS-38] [ 358.436677] [drm:drm_mode_getresources] [ENCODER:40:DP MST-40] [ 358.436678] [drm:drm_mode_getresources] [ENCODER:41:DP MST-41] [ 358.436678] [drm:drm_mode_getresources] [ENCODER:42:DP MST-42] [ 358.436679] [drm:drm_mode_getresources] [ENCODER:47:TMDS-47] [ 358.436680] [drm:drm_mode_getresources] [ENCODER:49:TMDS-49] [ 358.436681] [drm:drm_mode_getresources] [ENCODER:51:DP MST-51] [ 358.436682] [drm:drm_mode_getresources] [ENCODER:52:DP MST-52] [ 358.436682] [drm:drm_mode_getresources] [ENCODER:53:DP MST-53] [ 358.436683] [drm:drm_mode_getresources] [CONNECTOR:36:VGA-1] [ 358.436684] [drm:drm_mode_getresources] [CONNECTOR:39:DP-1] [ 358.436685] [drm:drm_mode_getresources] [CONNECTOR:45:HDMI-A-1] [ 358.436686] [drm:drm_mode_getresources] [CONNECTOR:48:HDMI-A-2] [ 358.436687] [drm:drm_mode_getresources] [CONNECTOR:50:DP-2] [ 358.436687] [drm:drm_mode_getresources] [CONNECTOR:54:HDMI-A-3] [ 358.436688] [drm:drm_mode_getresources] CRTC[3] CONNECTORS[6] ENCODERS[10] [ 358.436693] [drm:drm_mode_getconnector] [CONNECTOR:36:?] [ 358.436695] [drm:drm_mode_getconnector] [CONNECTOR:36:?] [ 358.436697] [drm:drm_mode_getconnector] [CONNECTOR:39:?] [ 358.436701] [drm:drm_mode_getconnector] [CONNECTOR:39:?] [ 358.436709] [drm:drm_mode_getconnector] [CONNECTOR:45:?] [ 358.436710] [drm:drm_mode_getconnector] [CONNECTOR:45:?] [ 358.436712] [drm:drm_mode_getconnector] [CONNECTOR:48:?] [ 358.436713] [drm:drm_mode_getconnector] [CONNECTOR:48:?] [ 358.436715] [drm:drm_mode_getconnector] [CONNECTOR:50:?] [ 358.436716] [drm:drm_mode_getconnector] [CONNECTOR:50:?] [ 358.436718] [drm:drm_mode_getconnector] [CONNECTOR:54:?] [ 358.436719] [drm:drm_mode_getconnector] [CONNECTOR:54:?] [ 358.436821] [drm:drm_mode_addfb2] [FB:79] [ 358.436829] [drm:drm_mode_addfb2] [FB:80] [ 358.436840] [drm:drm_mode_addfb2] [FB:81] [ 358.436851] [drm:drm_mode_addfb2] [FB:82] [ 358.436863] [drm:drm_mode_addfb2] [FB:83] [ 358.437186] kms_frontbuffer_tracking: starting subtest fbc-1p-primscrn-spr-indfb-fullscreen [ 358.437214] Setting dangerous option i915.enable_fbc - tainting kernel [ 358.437223] Setting dangerous option i915.enable_psr - tainting kernel [ 358.437228] [drm:drm_mode_setcrtc] [CRTC:26:crtc-0] [ 358.437245] [drm:hsw_audio_codec_disable] Disable audio codec on pipe A [ 358.437249] [drm:intel_disable_pipe] disabling pipe A [ 358.451607] [drm:__intel_fbc_disable] Disabling FBC on pipe A [ 358.451617] [drm:intel_power_well_disable] disabling always-on [ 358.451618] [drm:intel_power_well_disable] disabling display [ 358.451620] [drm:hsw_set_power_well] Requesting to disable the power well [ 358.451624] [drm:intel_connector_check_state] [CONNECTOR:39:DP-1] [ 358.451625] [drm:intel_power_well_enable] enabling always-on [ 358.451626] [drm:intel_power_well_disable] disabling always-on [ 358.451628] [drm:check_encoder_state] [ENCODER:37:DAC-37] [ 358.451629] [drm:intel_power_well_enable] enabling always-on [ 358.451630] [drm:intel_power_well_disable] disabling always-on [ 358.451631] [drm:check_encoder_state] [ENCODER:38:TMDS-38] [ 358.451632] [drm:intel_power_well_enabl
Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"
On May 06 Daniel Vetter wrote: > On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote: [...] > > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s) > > This one failed in both runs. Can you please retest with just that using > > # kms_frontbuffer_tracking --run-subtest fbc-1p-primscrn-spr-indfb-fullscreen > > Also please boot with drm.debug=0xe and grab the full dmesg of just that > single subtest. There's definitely something going wrong here. I performed this test with - plain v4.6-rc6, - v4.6-rc6 patched with drm-intel-nightly (2016y-05m-06d-14h-29m-58s). On v4.6-rc6, the test failed thus: 8< Subtest fbc-1p-primscrn-spr-indfb-fullscreen failed. DEBUG (kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: fbc.can_test (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, tiling=0x101, size=14745600) (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=6, pitch=10240) (kms_frontbuffer_tracking:1914) DEBUG: Blue CRC: pipe:[2ca73d01 ] sink:[unsupported!] (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, tiling=0x101, size=14745600) (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=6, pitch=10240) (kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5 (kms_frontbuffer_tracking:1914) DEBUG: Rect 0 CRC: pipe:[febb8b20 ] sink:[unsupported!] (kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5 (kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01 ] sink:[unsupported!] (kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: !fbc_not_enough_stolen() (kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01 ] sink:[unsupported!] (kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5 (kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01 ] sink:[unsupported!] (kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: !fbc_not_enough_stolen() (kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01 ] sink:[unsupported!] (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, tiling=0x101, size=14745600) (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd) (kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=6, pitch=10240) (kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[febb8b20 ] sink:[unsupported!] (kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: !fbc_not_enough_stolen() (kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[febb8b20 ] sink:[unsupported!] (kms_frontbuffer_tracking:1914) igt-core-INFO: Timed out: CRC reading END IGT-Version: 1.14-gc03a8ae6bf2f (x86_64) (Linux: 4.6.0-rc6 x86_64) Primary screen: DP 2560x1440, crtc 26 FBC last action not supported Can't test PSR: no usable eDP screen. Sink CRC not supported: primary screen is not eDP Timed out: CRC reading Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.806s) >8 On v4.6-rc6 plus drm-intel-nightly, the test apparently passed: 8< IGT-Version: 1.14-gc03a8ae6bf2f (x86_64) (Linux: 4.6.0-rc6+intel-drm-nightly x86_64) Primary screen: DP 2560x1440, crtc 26 FBC last action not supported Can't test PSR: no usable eDP screen. Sin
Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"
On May 08 Stefan Richter wrote: > On May 05 Zanoni, Paulo R wrote: > > If you don't want to keep carrying a manual revert, you can just boot > > with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also, > > it would be good to know in case you still somehow see the machine > > hangs even with FBC disabled. > > As expected, i915.enable_fbc=0 works fine. > No freeze within 2.5 days uptime; tested on v4.6-rc6. Furthermore, I checked out drm-intel.git (v4.6-rc6-962-g91567024d358 "drm-intel-nightly: 2016y-05m-06d-14h-29m-58s UTC integration manifest") and applied "git diff v4.6-rc6..." on top of v4.6-rc6. I booted the result once with default i915.enable_fbc, i.e. FBC enabled, performed the test which Daniel asked for (I will post the results in another message), then started X11. - The good news: I was able to switch back and forth between the sddm greeter screen on tty7, the text consoles at tty1...6, and the logger at tty12 --- without getting any FIFO underrun messages and without getting stuck with a blank screen. - The bad news: Less than a minute after login into sddm, just after having started openbox + lxpanel + konsole, the kernel froze again without netconsole output. I am now on 4.6.0-rc6+intel-drm-nightly with i915.enable_fbc=0. This is running fine so far. (uptime is just 30 minutes now though, so that doesn't say a lot.) Again, switching between ttys works without FIFO underruns, unlike plain v4.6-rc6. Not sure if it is coincidence or if this is because somebody fixed something. Like v4.6-rc6 and older,4.6.0-rc6+intel-drm-nightly still exhibits the following behaviour: If I switch the displayport connected monitor off and on again, the following messages are logged when the monitor comes on: [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe A [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun Other than these messages, there is nothing extraordinary going on. -- Stefan Richter -==- -=-= -=--- http://arcgraph.de/sr/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"
On May 05 Zanoni, Paulo R wrote: > If you don't want to keep carrying a manual revert, you can just boot > with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also, > it would be good to know in case you still somehow see the machine > hangs even with FBC disabled. As expected, i915.enable_fbc=0 works fine. No freeze within 2.5 days uptime; tested on v4.6-rc6. -- Stefan Richter -==- -=-= -=--- http://arcgraph.de/sr/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms
On Fri, May 06, 2016 at 09:22:49PM +0100, Chris Wilson wrote:
> On Fri, May 06, 2016 at 09:35:55PM +0300, ville.syrj...@linux.intel.com wrote:
> > @@ -730,9 +730,14 @@ int i915_suspend_switcheroo(struct drm_device *dev,
> > pm_message_t state)
> > static int i915_drm_resume(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > + int ret;
> >
> > disable_rpm_wakeref_asserts(dev_priv);
> >
> > + ret = i915_ggtt_enable_hw(dev);
> > + if (ret)
> > + DRM_ERROR("failed to re-enable GGTT\n");
>
> Would it not be fatal for resume as well? Failure means we can't use the
> GGTT, so all subsequent writes will be going into a random address.
Yeah, I assume things would blow up. The question is however, what can
we do in this case? We'd basically have to shut the entire driver down.
I don't think we have a way to do that?
--
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 v3 00/16] Pre-calculate SKL-style atomic watermarks
Hi Matt, On 22 April 2016 at 00:16, Matt Roper wrote: > For a detailed explanation of this series, please see the original cover > letter: > https://lists.freedesktop.org/archives/intel-gfx/2016-April/091293.html > > This spin just incorporates the final review feedback from Maarten and > hopefully kicks the CI system (I never got any CI test results back from v2). For the series, with Maarten and Lyude's amendments: Tested-by: Daniel Stone I was seeing pretty savage underflows on eDP+DP SKL, but these have gone away with this patchset on top of -nightly. Cheers, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
