Re: [Intel-gfx] [PATCH 19/30] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()

one already solves the issue... Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +- > drivers/gpu/drm/drm_dp_helper.c | 3 ++- > drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +- > drive

Re: [PATCH v3 2/2] drm/i915/icp+: Use icp_hpd_irq_setup() instead of spt_hpd_irq_setup()

; be calling icp_hpd_irq_setup() to ensure that CML-S/TGP platforms function > correctly anyway, let's move platforms using PCH_ICP which aren't handled > by gen11_hpd_irq_setup() over to icp_hpd_irq_setup(). > > Cc: Tejas Upadhyay > Signed-off-by: Lyude Paul makes sense to m

Re: [Intel-gfx] [PATCH v5 4/4] drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos

On Wed, Feb 10, 2021 at 10:23:58PM -0500, Rodrigo Vivi wrote: > On Tue, Feb 09, 2021 at 04:28:31PM -0500, Lyude Paul wrote: > > Apparently the new gen9_bc platforms that Intel has introduced don't > > provide us with a STRAP config register to read from for initializing DDI

Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers

On Mon, Feb 08, 2021 at 06:39:00PM -0500, Lyude Paul wrote: > Since we're about to implement eDP backlight support in nouveau using the > standard protocol from VESA, we might as well just take the code that's > already written for this and move it into a set of shared DRM helpers. > > Note that

Re: [RFC v4 05/11] drm/i915/dpcd_bl: Cleanup intel_dp_aux_vesa_enable_backlight() a bit

_CONTROL_MODE_MASK - imirkin > > Signed-off-by: Lyude Paul Reviewed-by: Rodrigo Vivi > --- > .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 ++- > 1 file changed, 2 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_

Re: [Intel-gfx] [RFC v4 08/11] drm/i915/dpcd_bl: Return early in vesa_calc_max_backlight if we can't read PWMGEN_BIT_COUNT

l on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in > doing this, so just return early. > > Signed-off-by: Lyude Paul Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > &g

Re: [Intel-gfx] [RFC v4 09/11] drm/i915/dpcd_bl: Print return codes for VESA backlight failures

give > us that anyway). > > Signed-off-by: Lyude Paul Reviewed-by: Rodrigo Vivi > --- > .../drm/i915/display/intel_dp_aux_backlight.c | 101 +- > 1 file changed, 52 insertions(+), 49 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_back

Re: [Intel-gfx] [PATCH v5 2/4] drm/i915/gen9_bc: Introduce TGP PCH DDC pin mappings

ncoder) > ddc_pin = dg1_port_to_ddc_pin(dev_priv, port); > else if (IS_ROCKETLAKE(dev_priv)) > ddc_pin = rkl_port_to_ddc_pin(dev_priv, port); > + else if (IS_GEN9_BC(dev_priv) && HAS_PCH_TGP(dev_priv)) > + ddc_pin = gen9bc_

Re: [PATCH v5 4/4] drm/i915/gen9_bc: Add W/A for missing STRAP config on TGP PCH + CML combos

On Tue, Feb 09, 2021 at 04:28:31PM -0500, Lyude Paul wrote: > Apparently the new gen9_bc platforms that Intel has introduced don't > provide us with a STRAP config register to read from for initializing DDI > B, C, and D detection. So, workaround this by hard-coding our strap config > in

Re: [PATCH v5 3/4] drm/i915/gen9_bc: Introduce HPD pin mappings for TGP PCH + CML combos

ce skl_hpd_pin() like vsyrjala suggested and use that instead of > sticking our HPD pin mappings in TGP code > > Cc: Matt Roper > Cc: Jani Nikula > Cc: Ville Syrjala > [originally from Tejas's work] > Signed-off-by: Tejas Upadhyay > Signed-off-by: Lyude Paul Reviewed-by

Re: [Intel-gfx] [PATCH v5 1/4] drm/i915/gen9_bc: Recognize TGP PCH + CML combos

n patch - vsyrjala > > Cc: Matt Roper > Cc: Jani Nikula > Cc: Ville Syrjala > [originally from Tejas's work] > Signed-off-by: Tejas Upadhyay > Signed-off-by: Lyude Paul Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_pch.c | 3 ++- > 1 file changed

Re: [RFC v3 07/10] drm/i915/dpcd_bl: Move VESA backlight enabling code closer together

On Fri, Feb 05, 2021 at 06:45:11PM -0500, Lyude Paul wrote: > No functional changes, just move set_vesa_backlight_enable() closer to it's > only caller: intel_dp_aux_vesa_enable_backlight(). > > Signed-off-by: Lyude Paul Reviewed-by: Rodrigo Vivi > --- > ..

Re: [RFC v3 06/10] drm/i915/dpcd_bl: Cache some backlight capabilities in intel_panel.backlight

match up with what we > actually need to use them for, like DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT > for instance). > > Signed-off-by: Lyude Paul Reviewed-by: Rodrigo Vivi > --- > .../drm/i915/display/intel_display_types.h| 2 ++ > .../drm/i915/display/intel_dp_aux_backl

Re: [RFC v3 04/10] drm/i915/dpcd_bl: Handle drm_dpcd_read/write() return values correctly

n values from each function > correctly. > > Signed-off-by: Lyude Paul Reviewed-by: Rodrigo Vivi > --- > .../drm/i915/display/intel_dp_aux_backlight.c | 41 +-- > 1 file changed, 19 insertions(+), 22 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display

Re: [RFC v2 4/5] drm/dp: Extract i915's eDP backlight code into DRM helpers

On Mon, Jan 25, 2021 at 07:10:30PM -0500, Lyude Paul wrote: > Since we're about to implement eDP backlight support in nouveau using the > standard protocol from VESA, we might as well just take the code that's > already written for this and move it into a set of shared DRM helpers. > > Note that

Re: linux-next: build failure after merge of the drm-intel-fixes tree

On Wed, Nov 04, 2020 at 09:37:05AM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the drm-intel-fixes tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'gen12_emit_fini_breadcrumb': >

Re: [Intel-gfx] [RFC v2 3/8] drm/i915: Keep track of pwm-related backlight hooks separately

On Wed, Sep 16, 2020 at 01:18:50PM -0400, Lyude Paul wrote: > Currently, every different type of backlight hook that i915 supports is > pretty straight forward - you have a backlight, probably through PWM > (but maybe DPCD), with a single set of platform-specific hooks that are > used for

Re: [Intel-gfx] [RFC v2 4/8] drm/i915/dp: Rename eDP VESA backlight interface functions

vesa to make it clear that they're specific to the VESA interface and > not Intel's. > > Signed-off-by: Lyude Paul > Cc: thay...@noraisin.net > Cc: Vasily Khoruzhick Reviewed-by: Rodrigo Vivi > --- > .../drm/i915/display/intel_dp_aux_backlight.c | 51 ++- >

Re: [RFC v2 1/8] drm/i915/dp: Program source OUI on eDP panels

* already set to what we want, so as to avoid clearing any state by > accident > + */ > + if (careful) { my first reaction here is why the problem described on the commit message doesn't appear during the init, and setting it to the same shouldn't be a problem... but yeap, I a

Re: [RFC 4/5] drm/i915: Enable Intel's HDR backlight interface (only SDR for now)

On Tue, Sep 15, 2020 at 01:29:38PM -0400, Lyude Paul wrote: > So-recently a bunch of laptops on the market have started using DPCD > backlight controls instead of the traditional DDI backlight controls. > Originally we thought we had this handled by adding VESA backlight > control support to i915,

Re: [RFC 1/5] drm/i915/dp: Program source OUI on eDP panels

On Tue, Sep 15, 2020 at 01:29:35PM -0400, Lyude Paul wrote: > Since we're about to start adding support for Intel's magic HDR > backlight interface over DPCD, we need to ensure we're properly > programming this field so that Intel specific sink services are exposed. > Otherwise, 0x300-0x3ff will

Re: [git pull] drm fixes for 5.7-rc8/final

On Fri, May 29, 2020 at 12:15:27PM +1000, Dave Airlie wrote: > On Fri, 29 May 2020 at 12:02, Dave Airlie wrote: > > > > On Fri, 29 May 2020 at 11:49, Linus Torvalds > > wrote: > > > > > > On Thu, May 28, 2020 at 5:21 PM Dave Airlie wrote: > > > > > > > > Seems to have wound down nicely, a

Current LTS and their EOL

Hi Greg, Ben, and all Is https://www.kernel.org/category/releases.html updated in terms of EOL? Some news out of Linaro conference [2] generated a lot of doubts and questions around. Specially because on the way it was stated by the news 3.16 wouldn't be active anymore. So I'm not sure about

Current LTS and their EOL

Hi Greg, Ben, and all Is https://www.kernel.org/category/releases.html updated in terms of EOL? Some news out of Linaro conference [2] generated a lot of doubts and questions around. Specially because on the way it was stated by the news 3.16 wouldn't be active anymore. So I'm not sure about

Re: [Intel-gfx] [PATCH] gpu: drm: i915: Change return type to vm_fault_t

On Wed, Apr 18, 2018 at 08:46:44AM +0300, Jani Nikula wrote: > On Tue, 17 Apr 2018, Souptick Joarder wrote: > > On 17-Apr-2018 9:45 PM, "Matthew Wilcox" wrote: > >> > >> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote: > >> > Not

Re: [Intel-gfx] [PATCH] gpu: drm: i915: Change return type to vm_fault_t

On Wed, Apr 18, 2018 at 08:46:44AM +0300, Jani Nikula wrote: > On Tue, 17 Apr 2018, Souptick Joarder wrote: > > On 17-Apr-2018 9:45 PM, "Matthew Wilcox" wrote: > >> > >> On Tue, Apr 17, 2018 at 09:14:32PM +0530, Souptick Joarder wrote: > >> > Not exactly. The plan for these patches is to

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote: > On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

On Tue, Apr 17, 2018 at 12:02:52PM +0300, Jani Nikula wrote: > On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON > >>Cc: Vivi, Rodrigo ;

Re: linux-next: manual merge of the drm tree with Linus' tree

On Mon, Feb 19, 2018 at 10:10:50AM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm tree got a conflict in: > > drivers/gpu/drm/i915/intel_breadcrumbs.c > > between commit: > > 117172c8f9d4 ("drm/i915/breadcrumbs: Ignore unsubmitted signalers") > > from

Re: linux-next: manual merge of the drm tree with Linus' tree

On Mon, Feb 19, 2018 at 10:10:50AM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm tree got a conflict in: > > drivers/gpu/drm/i915/intel_breadcrumbs.c > > between commit: > > 117172c8f9d4 ("drm/i915/breadcrumbs: Ignore unsubmitted signalers") > > from

Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)

On Sat, Dec 30, 2017 at 12:53:58PM +, Jiri Kosina wrote: > On Sat, 30 Dec 2017, Jiri Kosina wrote: > > > Seems like disabling RC6 on the kernel command line works this around, and > > I can dock / undock several times in a row with the image always coming > > up properly on the external

Re: [Intel-gfx] Graphics on thinkpad x270 after dock/undock works only for the first time (CPU pipe B FIFO underrun)

On Sat, Dec 30, 2017 at 12:53:58PM +, Jiri Kosina wrote: > On Sat, 30 Dec 2017, Jiri Kosina wrote: > > > Seems like disabling RC6 on the kernel command line works this around, and > > I can dock / undock several times in a row with the image always coming > > up properly on the external

Re: [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote: > The ACK/NACK implementation as found in e.g. the G965 has the falling > clock edge and the release of the data line after the ACK for the received > byte happen at the same time. > > This is conformant with the I2C specification,

Re: [PATCH v2] drm/i915: Try EDID bitbanging on HDMI after failed read

On Sun, Dec 31, 2017 at 10:34:54PM +, Stefan Brüns wrote: > The ACK/NACK implementation as found in e.g. the G965 has the falling > clock edge and the release of the data line after the ACK for the received > byte happen at the same time. > > This is conformant with the I2C specification,

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

On Wed, Dec 06, 2017 at 01:00:15AM +, Stephen Rothwell wrote: > Hi all, Hi Stephen, I had just written the email for you about this. Feel free to ignore that one since you already found the solution and sorry for the delay on warning you. > > After merging the drm-misc tree, today's

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

On Wed, Dec 06, 2017 at 01:00:15AM +, Stephen Rothwell wrote: > Hi all, Hi Stephen, I had just written the email for you about this. Feel free to ignore that one since you already found the solution and sorry for the delay on warning you. > > After merging the drm-misc tree, today's

Re: [Intel-gfx] [haswell_crtc_enable] WARNING: CPU: 3 PID: 109 at drivers/gpu/drm/drm_vblank.c:1066 drm_wait_one_vblank+0x18f/0x1a0 [drm]

On Mon, Oct 30, 2017 at 07:10:11PM +, Linus Torvalds wrote: > On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote: > > CC intel-gfx. > > Thanks, these are all interesting (even if some of them seem to be > from random kernels). > > Fengguang, is this a new script

Re: [Intel-gfx] [haswell_crtc_enable] WARNING: CPU: 3 PID: 109 at drivers/gpu/drm/drm_vblank.c:1066 drm_wait_one_vblank+0x18f/0x1a0 [drm]

On Mon, Oct 30, 2017 at 07:10:11PM +, Linus Torvalds wrote: > On Mon, Oct 30, 2017 at 12:00 AM, Fengguang Wu wrote: > > CC intel-gfx. > > Thanks, these are all interesting (even if some of them seem to be > from random kernels). > > Fengguang, is this a new script that you started running?

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

On Wed, Oct 11, 2017 at 08:51:06AM +, Mark Brown wrote: > On Tue, Oct 10, 2017 at 08:03:00AM +0100, Mark Brown wrote: > > Hi all, > > > > After merging the drm-misc-fixes tree, today's linux-next build > > (x86_allmodconfig) failed like this: > > > > CC [M]

Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree

On Wed, Oct 11, 2017 at 08:51:06AM +, Mark Brown wrote: > On Tue, Oct 10, 2017 at 08:03:00AM +0100, Mark Brown wrote: > > Hi all, > > > > After merging the drm-misc-fixes tree, today's linux-next build > > (x86_allmodconfig) failed like this: > > > > CC [M]

[git pull] drm/i915 fixes for v4.14-rc1

duplicated MMIO Manasi Navare (1): drm/i915/edp: Increase T12 panel delay to 900 ms to fix DP AUX CH timeouts Rodrigo Vivi (1): Merge tag 'gvt-fixes-2017-09-06' of https://github.com/01org/gvt-linux into drm-intel-next-fixes Ville Syrjälä (7): drm/i915: Treat fb->offsets[] as a

[git pull] drm/i915 fixes for v4.14-rc1

duplicated MMIO Manasi Navare (1): drm/i915/edp: Increase T12 panel delay to 900 ms to fix DP AUX CH timeouts Rodrigo Vivi (1): Merge tag 'gvt-fixes-2017-09-06' of https://github.com/01org/gvt-linux into drm-intel-next-fixes Ville Syrjälä (7): drm/i915: Treat fb->offsets[] as a

Re: [PATCH v2] drm/i915: Return correct EDP voltage swing table for 0.85V

_______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Rodrigo Vivi Blog: http://blog.vivi.eng.br

Re: [PATCH v2] drm/i915: Return correct EDP voltage swing table for 0.85V

: Manasi Navare > > ping, it seems this patch went under the radar. yes totally. sorry about that. merged to dinq. Thanks for patch, review, and heads up > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Rodrigo Vivi Blog: http://blog.vivi.eng.br

Re: [PATCH 04/10] drm: make drm_vblank_{get,put}() static

Oh, nevermind... I saw the places that depends on changes on other legacy usage like drm_wait_on_vblank... (not trivial on intel_crt) and other cases... So better to just go with the static for now. Feel free to use: Reviewed-by: Rodrigo Vivi <rodrigo.v...@intel.com> On Wed, Aug 3, 2016

Re: [PATCH 04/10] drm: make drm_vblank_{get,put}() static

Oh, nevermind... I saw the places that depends on changes on other legacy usage like drm_wait_on_vblank... (not trivial on intel_crt) and other cases... So better to just go with the static for now. Feel free to use: Reviewed-by: Rodrigo Vivi On Wed, Aug 3, 2016 at 12:22 AM, Daniel Vetter

Re: [PATCH 04/10] drm: make drm_vblank_{get,put}() static

extern int drm_crtc_vblank_get(struct drm_crtc *crtc); > extern void drm_crtc_vblank_put(struct drm_crtc *crtc); > extern void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe); > -- > 2.5.5 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Rodrigo Vivi Blog: http://blog.vivi.eng.br

Re: [PATCH 04/10] drm: make drm_vblank_{get,put}() static

crtc *crtc); > extern void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe); > -- > 2.5.5 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Rodrigo Vivi Blog: http://blog.vivi.eng.br

Re: [PATCH] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7

On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote: > On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi wrote: > > On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote: > >> From: Duncan Laurie > >> > >> We had been using a DMI

Re: [PATCH] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7

On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote: > From: Duncan Laurie > > We had been using a DMI table workaround to select the right > frequency for devices, but this is fragile and must be updated > with every new platform. > > Instead the default case when VBT is missing is

Re: [PATCH] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7

On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote: From: Duncan Laurie dlau...@chromium.org We had been using a DMI table workaround to select the right frequency for devices, but this is fragile and must be updated with every new platform. Instead the default case when VBT

Re: [PATCH] i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7

On Thu, Nov 14, 2013 at 09:36:10AM -0800, Olof Johansson wrote: On Thu, Nov 14, 2013 at 8:53 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: On Wed, Nov 13, 2013 at 05:59:43PM -0800, Olof Johansson wrote: From: Duncan Laurie dlau...@chromium.org We had been using a DMI table workaround