Re: [Intel-gfx] [PATCH 2/6] drm/i915/icl: add the main CDCLK functions

On Mon, Feb 05, 2018 at 01:40:42PM -0200, Paulo Zanoni wrote: > This commit adds the basic CDCLK functions, but it's still missing > pieces of the display initialization sequence. > > v2: > - Implement the voltage levels. > - Rebase. > v3: > - Adjust to the new "bypass" clock (Imre). > - Call

Re: [Intel-gfx] [PATCH 6/8] drm/i915/icp: Add backlight Support for ICP

On Fri, Jan 19, 2018 at 10:48 AM, Paulo Zanoni wrote: > > From: Anusha Srivatsa > > ICP has two backlight controllers - similar to previous platforms like > BXT -, but we only use one controller for now, so we can just reuse > the CNP code. >

Re: [Intel-gfx] [PATCH] drm/i915: Protect DDI port to DPLL map from theoretical race.

On Fri, Dec 15, 2017 at 2:35 PM, Rodrigo Vivi wrote: > In case we have multiple modesets for different connectors > happening in parallel we could have a race on the RMW on these > shared registers. > > This possibility was initially raised by Paulo when reviewing > commit

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Pass the level to intel_prepare_hdmi_ddi_buffers()

On Mon, Oct 16, 2017 at 7:56 AM, Ville Syrjala wrote: > From: Ville Syrjälä > > The caller of intel_prepare_hdmi_ddi_buffers() alreday figured out the > level, so let's just pass it in instead if figuring it out again. > >

Re: [Intel-gfx] [PATCH v2 03/10] drm/i915: Pass the encoder type explicitly to skl_set_iboost()

On Mon, Oct 16, 2017 at 7:56 AM, Ville Syrjala wrote: > From: Ville Syrjälä > > encoder->type isn't reliable for DP/HDMI encoders, so pass the type > explicity to skl_set_iboost(). Also take the opportunity to streamline > the code. >

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Extract intel_ddi_get_buf_trans_hdmi()

On Mon, Oct 16, 2017 at 7:56 AM, Ville Syrjala wrote: > From: Ville Syrjälä > > Introduce intel_ddi_get_buf_trans_hdmi() and start using it where we > can. > > Signed-off-by: Ville Syrjälä > --- >

Re: [Intel-gfx] [PATCH v2 01/10] drm/i915: Relocate intel_ddi_get_buf_trans_*() functions

On Mon, Oct 16, 2017 at 7:56 AM, Ville Syrjala wrote: > From: Ville Syrjälä > > We'll want to use the intel_ddi_get_buf_trans_*() functions a bit > earlier in the file, so move them up. While at it start using them > in the iboost

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector (rev6)

On Fri, Oct 13, 2017 at 8:35 PM, Patchwork wrote: > == Series Details == > > Series: drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector (rev6) > URL : https://patchwork.freedesktop.org/series/30384/ > State : failure > > == Summary == > > Test

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bdw: Fix DP_AUX_CH_CTL_TIME_OUT setting

On Thu, Oct 12, 2017 at 1:59 PM, Rodrigo Vivi <rodrigo.v...@intel.com> wrote: > On Thu, Oct 12, 2017 at 06:58:20PM +0000, Ausmus, James wrote: >> On Wed, Oct 4, 2017 at 3:54 PM, Runyan, Arthur J >> <arthur.j.run...@intel.com> wrote: >> > I think the failure was

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector

On Wed, Sep 27, 2017 at 11:29 AM, James Ausmus wrote: > Make intel_dp_add_mst_connector handle error returns from the drm_ calls. > Add intel_connector_free to support cleanup on the error path. > > v2: Rename new function to avoid confusion, and simplify error > paths

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bdw: Fix DP_AUX_CH_CTL_TIME_OUT setting

d for merge now? Thanks! -James > -Original Message- > From: Vivi, Rodrigo > Sent: Wednesday, 4 October, 2017 1:25 PM > To: Ausmus, James <james.aus...@intel.com> > Cc: intel-gfx@lists.freedesktop.org; ville.syrj...@linux.intel.com; > jani.nik...@linux.intel.com; Runy

Re: [Intel-gfx] [PATCH 05/13] drm/i915/cnl: extract cnl_dvfs_{pre, post}_change

On Tue, Oct 3, 2017 at 12:06 AM, Rodrigo Vivi wrote: > From: Paulo Zanoni > > These functions even have their own page in our spec, > so extract them from cnl_set_cdclk(). > > v2: (By Rodrigo) Fixed inverted logic on error return of >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/cnl: Fix PLL initialization for HDMI.

On Tue, Oct 3, 2017 at 3:08 PM, Rodrigo Vivi wrote: > HDMI Mode selection on CNL is on CFGCR0 for that PLL, not > on in a global CTRL1 as it was on SKL. > > The original patch addressed this difference, but leaving behind > this single entry here. So we were checking the

Re: [Intel-gfx] [PATCH 1/2] drm/i915/cnl: Fix PLL mapping.

On Tue, Oct 3, 2017 at 3:08 PM, Rodrigo Vivi wrote: > On PLL Enable sequence we need to "Configure DPCLKA_CFGCR0 to turn on > the clock for the DDI and map the DPLL to the DDI" > > So we first do the map and then we unset DDI_CLK_OFF to turn the clock > on. We do this in 2

Re: [Intel-gfx] [PATCH i-g-t] Fix compilation on some distros

On Thu, Sep 28, 2017 at 1:40 AM, Petri Latvala wrote: > On Wed, Sep 27, 2017 at 04:08:27PM -0700, James Ausmus wrote: >> Some distros (such as Gentoo) are removing the include of >> sys/sysmacros.h from sys/types.h. Explicitly include sysmacros.h in >> files where we use

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Clean up intel_dp_check_mst_status

On Thu, Sep 21, 2017 at 11:54 AM, Dhinakaran Pandiyan wrote: > Rewriting this code without the goto, I believe, makes it more readable. > One functional change that has been included is the handling of failed ESI > register reads. Instead of disabling MST only for

Re: [Intel-gfx] [PATCH 4/5] drm/i915/dp: Clean up intel_dp_check_mst_status

On Wed, Sep 20, 2017 at 3:47 PM, Pandiyan, Dhinakaran <dhinakaran.pandi...@intel.com> wrote: > On Wed, 2017-09-20 at 13:02 -0700, Ausmus, James wrote: >> On Wed, Sep 20, 2017 at 12:55 PM, Pandiyan, Dhinakaran >> <dhinakaran.pandi...@intel.com> wrote: >> > On We

Re: [Intel-gfx] [PATCH 4/5] drm/i915/dp: Clean up intel_dp_check_mst_status

On Wed, Sep 20, 2017 at 12:55 PM, Pandiyan, Dhinakaran <dhinakaran.pandi...@intel.com> wrote: > On Wed, 2017-09-20 at 12:11 -0700, Ausmus, James wrote: >> On Mon, Sep 18, 2017 at 3:21 PM, Dhinakaran Pandiyan >> <dhinakaran.pandi...@intel.com> wrote: >> > Rew

Re: [Intel-gfx] [PATCH 4/5] drm/i915/dp: Clean up intel_dp_check_mst_status

On Mon, Sep 18, 2017 at 3:21 PM, Dhinakaran Pandiyan wrote: > Rewriting this code without the goto, I believe, makes it more readable. > One functional change that has been included is the handling of failed ESI > register reads. Instead of disabling MST only for

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector

On Fri, Sep 15, 2017 at 11:09 AM, Ville Syrjälä wrote: > On Fri, Sep 15, 2017 at 10:49:09AM -0700, James Ausmus wrote: >> Make intel_dp_add_mst_connector handle error returns from the drm_ calls. >> Add intel_connector_free to support cleanup on the error path. >>

Re: [Intel-gfx] [PATCH 8/9] drm/i915/dp: Protect link training with connection mutex

On Fri, Sep 15, 2017 at 11:38 AM, Manasi Navare <manasi.d.nav...@intel.com> wrote: > On Thu, Sep 14, 2017 at 03:26:37PM -0700, Ausmus, James wrote: >> On Tue, Sep 12, 2017 at 4:57 PM, Dhinakaran Pandiyan >> <dhinakaran.pandi...@intel.com> wrote: >> >

Re: [Intel-gfx] [PATCH] drm/i915: Handle drm-layer errors in intel_dp_add_mst_connector

On Fri, Sep 15, 2017 at 3:18 AM, Ville Syrjälä wrote: > On Thu, Sep 14, 2017 at 12:59:35PM -0700, James Ausmus wrote: >> Make intel_dp_add_mst_connector handle error returns from the drm_ calls. >> Add intel_connector_destroy to support cleanup on the error path. >

Re: [Intel-gfx] [PATCH 9/9] drm/i915/dp: Remove redundant can_mst checks in intel_dp_configure_mst()

On Tue, Sep 12, 2017 at 4:57 PM, Dhinakaran Pandiyan wrote: > intel_dp_can_mst() performs these checks. > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_dp.c | 6 -- > 1 file changed, 6 deletions(-) > >

Re: [Intel-gfx] [PATCH 8/9] drm/i915/dp: Protect link training with connection mutex

On Tue, Sep 12, 2017 at 4:57 PM, Dhinakaran Pandiyan wrote: > The other instances of link training are protected with > connection_mutex, so do the same in check_mst_status() too. We don't seem to be taking connection_mutex around intel_dp_start/stop_link_train in

Re: [Intel-gfx] [PATCH 6/9] drm/i915/dp: Handle check_mst_status() failure in one place

On Tue, Sep 12, 2017 at 4:57 PM, Dhinakaran Pandiyan wrote: > The caller already has code to handle failure, no need to duplicate > that. > > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_dp.c | 6 -- > 1

Re: [Intel-gfx] [PATCH 3/9] drm/i915/dp: Fix buffer size for sink_irq_esi read

On Tue, Sep 12, 2017 at 4:57 PM, Dhinakaran Pandiyan wrote: > The buffer size defined is 16 bytes whereas only 14 bytes are read. Add a > macro to avoid this discrepancy. > > Signed-off-by: Dhinakaran Pandiyan Reviewed-by: James

Re: [Intel-gfx] [PATCH 2/9] drm/i915/mst: Print active mst links after update

On Tue, Sep 12, 2017 at 4:57 PM, Dhinakaran Pandiyan wrote: > Both mst_disable_dp and mst_post_disable_dp print number of active links > before the variable has been updated. Move the print statement in > mst_disable_dp after the decrement so that the printed values

Re: [Intel-gfx] [PATCH 7/9] drm/i915/dp: Avoid double-printing esi regs

On Tue, Sep 12, 2017 at 4:57 PM, Dhinakaran Pandiyan wrote: > We debug log the esi dpcd's twice after reading them back, which is not > necessary. > > Signed-off-by: Dhinakaran Pandiyan While you're cleaning this up, why not move the

Re: [Intel-gfx] [PATCH 1/9] drm/i915/mst: Debug log connector name in destroy_connector()

On Tue, Sep 12, 2017 at 4:57 PM, Dhinakaran Pandiyan wrote: > Print connector name in destroy_connect() and this doesn't add any extra > lines to dmesg. The debug macro has been moved before the unregister > call so that we don't lose the connector name and id. > >

Re: [Intel-gfx] [RFC 1/1] drm/i915 : Wait until SYSTEM_RUNNING before loading CSR firmware

On Wed, Jul 15, 2015 at 2:34 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jul 14, 2015 at 01:37:32PM -0700, Greg KH wrote: On Tue, Jul 14, 2015 at 11:22:35AM +0200, Daniel Vetter wrote: On Mon, Jul 13, 2015 at 09:36:45AM -0700, jay.p.pa...@intel.com wrote: From: Jay Patel

Re: [Intel-gfx] [PATCH] drm/i915: Redo WMs when cursor size changes

On Thu, Feb 26, 2015 at 2:48 PM, Joe Konno joe.ko...@linux.intel.com wrote: From: Joe Konno joe.ko...@intel.com In instances where cursor sizes change, as in Chromium Ozone/Freon, watermarks should be recomputed. There should be no hard-coded assumptions about cursor widths. This was

Re: [Intel-gfx] [PATCH] drm/i915: Disable caches for Global GTT.

On Fri, Oct 31, 2014 at 5:27 AM, Rodrigo Vivi rodrigo.v...@intel.com wrote: Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000; So the only way to avoid screen corruptions is setting PAT 0 to Uncached. MOCS can still be used though. But if userspace is trusting PTE for

Re: [Intel-gfx] [PATCH] drm/i915: Disable caches for Global GTT.

On Fri, Oct 31, 2014 at 5:27 AM, Rodrigo Vivi rodrigo.v...@intel.com wrote: Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000; So the only way to avoid screen corruptions is setting PAT 0 to Uncached. MOCS can still be used though. But if userspace is trusting PTE for

Re: [Intel-gfx] [PATCH 00/12] Broadwell 3.14 backports

On Sat, Mar 22, 2014 at 4:34 AM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Mar 21, 2014 at 05:51:01PM -0700, Ben Widawsky wrote: Let's try this again. I've pushed a branch here: http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=bdw-backports I need to re-review some of the merge

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Restore PPAT on thaw

On Tue, Mar 18, 2014 at 4:09 PM, Ben Widawsky benjamin.widaw...@intel.com wrote: Apparently it is wiped out from under us, and we get some really fun caching artifacts upon resume (it seems to be WB for all types by default). Reported-by: James Ausmus james.aus...@intel.com Signed-off-by:

Re: [Intel-gfx] [PATCH 0/9] drm-intel-collector - update

On Mon, Nov 18, 2013 at 6:32 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: This is another drm-intel-collector updated notice: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector Here goes the update list in order for better reviewers assignment: Patch drm/i915:

Re: [Intel-gfx] intel_drv.so segfault

On Wed, Nov 6, 2013 at 6:22 AM, Grant emailgr...@gmail.com wrote: I'm getting the following segfault intermittently when using sna. I've tried xf86-video-intel-2.99.905 and the latest from git a week or so ago. Symbols, please. addr2line -e

Re: [Intel-gfx] intel_drv.so segfault

On Wed, Nov 6, 2013 at 10:17 AM, Grant emailgr...@gmail.com wrote: Thank you, here's what I get: # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f /var/tmp/portage/x11-drivers/xf86-video-intel-2.99.905-r1/work/xf86-video-intel-2.99.905/src/sna/sna_accel.c:6079

Re: [Intel-gfx] intel_drv.so segfault

On Wed, Nov 6, 2013 at 10:48 AM, Grant emailgr...@gmail.com wrote: Thank you, here's what I get: # addr2line -e /usr/lib64/xorg/modules/drivers/intel_drv.so -i 0x2fe79 0x3037f Grant - I'm assuming that this was done on the emerged xf86-video-intel, not the git-compiled one?

Re: [Intel-gfx] [RFC] drm/i915: Non-upstream ChromeOS patches from 3.8

On Fri, Aug 16, 2013 at 1:15 AM, Jani Nikula jani.nik...@linux.intel.com wrote: On Fri, 16 Aug 2013, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Aug 15, 2013 at 05:30:25PM -0700, james.aus...@intel.com wrote: Hello All- I'm trying to determine if the ChromeOS-only patches being carried