Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

Thanks Joonas. > -Original Message- > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Monday, May 8, 2017 6:19 PM > To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; > intel- > gvt-...@lists.freedesktop.org > Cc: Chris Wilson

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

Thanks Chris. > -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Monday, May 8, 2017 8:11 PM > To: Joonas Lahtinen > Cc: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; > intel- >

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote: > Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs. > Some of these are used by media-sdk; if these entries are missing > the default will instead be to do everything uncached. > > This patch improves

Re: [Intel-gfx] [maintainer-tools PATCH] docs: drm-misc: Remove misc-next merges during merge window/rc1

On Fri, May 05, 2017 at 11:39:13AM -0400, Sean Paul wrote: > In the merge timeline, remove the misc-next ~> drm-next merges while > the merge window is active, and during rc1. Pulls should only be requested > between rc2 and rc5. > > Signed-off-by: Sean Paul Ah, I didn't

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

On Mon, 08 May 2017, Daniel Vetter wrote: > On Fri, May 05, 2017 at 08:40:43PM +0300, 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

[Intel-gfx] Question about relationship between intel-gfx-SVM and PASID

Hi, I am a newbie on the intel-gfx and tries to use the shared virtual memory  which is mentioned in several intel documents (vt-d and Intel-gfx-prm)supported in the opencl library to share address space betweenCPU and intel integrated GPU.As far as I know, shared virtual memory is supported as

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 5, 2017 at 12:24 PM, Andy Shevchenko wrote: > On Fri, 2017-05-05 at 10:06 +0300, Amir Goldstein wrote: [...] >> I think with this semantic change, our proposals can reach common >> grounds >> and satisfy a wider group of users (i.e. filesystem

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 5, 2017 at 12:57 PM, Christoph Hellwig wrote: > On Fri, May 05, 2017 at 12:50:31PM +0300, Amir Goldstein wrote: >> To complete the picture for folks not cc'ed on my patches, >> xfs use case suggests there is also justification for the additional helpers: >> >>

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

On Fri, May 5, 2017 at 9:20 AM, Dan Williams wrote: > On Thu, May 4, 2017 at 2:21 AM, Andy Shevchenko > wrote: >> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 >> bytes. Instead we convert them to use uuid_le

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

On Sun, 07 May 2017, Hans de Goede wrote: > @@ -1403,6 +1410,31 @@ static inline u32 intel_plane_ggtt_offset(const struct > intel_plane_state *state) > return i915_ggtt_offset(state->vma); > } > > +static inline unsigned int > +intel_plane_get_rotation(const struct

Re: [Intel-gfx] [PATCH] drm/i915: use memdup_user_nul

On Sat, May 06, 2017 at 11:40:17PM +0800, Geliang Tang wrote: > Use memdup_user_nul() helper instead of open-coding to simplify the > code. > > Signed-off-by: Geliang Tang Thx for the patch, applied to drm-intel.git. -Daniel > --- > drivers/gpu/drm/i915/i915_debugfs.c

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

On Fri, May 05, 2017 at 08:40:43PM +0300, 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

Re: [Intel-gfx] [PATCH 4/4] drm/i915/psr: Account for sink CRC raciness on some panels

On Sat, 06 May 2017, Jim Bride wrote: > According to the eDP spec, when the count field in TEST_SINK_MISC > increments then the six bytes of sink CRC information in the DPCD > should be valid. Unfortunately, this doesn't seem to be the case > on some panels, and as a

Re: [Intel-gfx] [PATCH] drm/i915: Restore GT performance in headless mode with DMC loaded

On Fri, 05 May 2017, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > It seems that the DMC likes to transition between the DC states > a lot when there are no connected displays (no active power > domains) during simple command submission. > >

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

On la, 2017-05-06 at 02:58 +, Zhang, Xiong Y wrote: > > > > On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > + David and Jon > > > > > > > > > > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote: > > > > > > > > > > The

Re: [Intel-gfx] [PATCH] drm/i915: Make vblank evade warnings optional

On Sun, May 07, 2017 at 08:12:52PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Add a new Kconfig option to enable/disable the extra warnings > from the vblank evade code. For now we'll keep the warning > about an actually missed vblank

Re: [Intel-gfx] [PATCH] drm/i915: Make vblank evade warnings optional

On Sun, May 07, 2017 at 07:52:14PM -0600, Jens Axboe wrote: > On 05/07/2017 11:56 AM, Daniel Vetter wrote: > > On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote: > >> On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote: > >>> From: Ville Syrjälä

Re: [Intel-gfx] [PATCH 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP

On Sat, 06 May 2017, Jim Bride wrote: > This set of changes has some history to them. There were several attempts > to add what was called "fast link training" to i915, which actually wasn't > fast link training as per the DP spec. These changes were > > 5fa836a9d859

[Intel-gfx] [PATCH] drm/i915: Work around for underrun when enabling pipe scaler in GLK

In Geminilake, a FIFO underrun happens the first time a pipe scaler is enabled after boot/resume from suspend. Disabling DPF clock gating in the respective CLKGATE_DIS_PSL register prior to enabling the scaler works around the issue. Signed-off-by: Ander Conselvan de Oliveira

Re: [Intel-gfx] [PATCH 1/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.

On Sat, 06 May 2017, Jim Bride wrote: > Some fixed resolution panels actually support more than one mode, > with the only thing different being the refresh rate. Having this > alternate mode available to us is desirable, because it allows us to > test PSR on panels

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

Hi, On 08-05-17 10:25, Jani Nikula wrote: On Sun, 07 May 2017, Hans de Goede wrote: @@ -1403,6 +1410,31 @@ static inline u32 intel_plane_ggtt_offset(const struct intel_plane_state *state) return i915_ggtt_offset(state->vma); } +static inline unsigned int

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Work around for underrun when enabling pipe scaler in GLK

== Series Details == Series: drm/i915: Work around for underrun when enabling pipe scaler in GLK URL : https://patchwork.freedesktop.org/series/24100/ State : success == Summary == Series 24100v1 drm/i915: Work around for underrun when enabling pipe scaler in GLK

Re: [Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Friday, May 5, 2017 5:11 PM > To: Joonas Lahtinen > Cc: Zhenyu Wang ; Dong, Chuanxiao > ; Daniel Vetter

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

Hi, On 08-05-17 12:44, Ville Syrjälä wrote: On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote: On some (Bay Trail) devices the LCD panel is mounted upside-down. This commit uses the code to read back the initial rotation of the primary plane in get_initial_plane_config from Ville

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

On ma, 2017-05-08 at 02:49 +, Li, Weinan Z wrote: > Hi Joonas/Chris, do you have any comments? > I've asked OCL team for this patch, they also agree to use available aperture > size > for max allocation buffer definition, code confirmation ongoing. The patch title should be corrected to

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote: > On some (Bay Trail) devices the LCD panel is mounted upside-down. > > This commit uses the code to read back the initial rotation of the > primary plane in get_initial_plane_config from Ville Syrjala's > "drm/fb-helper: Inherit

Re: [Intel-gfx] [PATCH] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

On ma, 2017-05-08 at 10:30 +, Dong, Chuanxiao wrote: > > > > > + if (i915.enable_guc_submission) { > > > > > + DRM_INFO("GPU guest virtualisation [GVT-g] disabled due > > > > > to > > > > > +enabled GuC submission [i915.enable_guc_submission module > > > > >

Re: [Intel-gfx] [PATCH] drm/i915/guc: Dump the GuC stage descriptor pool in debugfs

On pe, 2017-05-05 at 14:34 +, Oscar Mateo wrote: > We are missing pieces of information that could be useful for GuC > debugging. > > Cc: Daniele Ceraolo Spurio > Cc: Joonas Lahtinen > Signed-off-by: Oscar Mateo

[Intel-gfx] [PATCH v2] drm/i915: Restore GT performance in headless mode with DMC loaded

From: Tvrtko Ursulin It seems that the DMC likes to transition between the DC states a lot when there are no connected displays (no active power domains) during simple command submission. This frantic activity on DC states has a terrible impact on the performance of

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Make scratch register base and count flexible

On pe, 2017-05-05 at 11:35 +, Michal Wajdeczko wrote: > We are using some scratch registers in MMIO based send function. > Make their base and count flexible in preparation of upcoming > GuC firmware/hardware changes. While around, change cmd len > parameter verification from WARN_ON to

Re: [Intel-gfx] [PATCH 5/5] drm/vblank: Lock down vblank->hwmode more

On Thu, May 04, 2017 at 03:20:22PM +0200, Daniel Vetter wrote: > On Wed, May 03, 2017 at 05:09:08PM +0300, Ville Syrjälä wrote: > > On Wed, May 03, 2017 at 09:26:38AM +0200, Daniel Vetter wrote: > > > In the previous patch we've implemented hwmode tracking a la i915 for > > > the vblank timestamp

[Intel-gfx] [PATCH 09/11] drm/i915/skl+: use linetime latency if ddb size is not available

This patch make changes to use linetime latency if allocated DDB size during plane watermark calculation is not available, This is required to implement new DDB allocation algorithm. In New Algorithm DDB is allocated based on WM values, because of which number of DDB blocks will not be available

[Intel-gfx] [PATCH 10/11] drm/i915/skl: New ddb allocation algorithm

This patch implements new DDB allocation algorithm as per HW team recommendation. This algo takecare of scenario where we allocate less DDB for the planes with lower relative pixel rate, but they require more DDB to work. It also takes care of enabling same watermark level for each plane in crtc,

[Intel-gfx] [PATCH 02/11] drm/i915: Add more wrapper for fixed_point_16_16 operations

This patch adds few wrapper to perform fixed_point_16_16 operations mul_u32_fixed_16_16_round_up : Multiplies u32 and fixed_16_16_t variables & returns u32 result with rounding-off. mul_fixed_16_16 : Multiplies two fixed_16_16_t

[Intel-gfx] [PATCH 00/11] Implement DDB algorithm and WM cleanup

This series implements new DDB allocation algorithm to solve the cases, where we have sufficient DDB available to enable multiple planes, But due to the current algorithm not dividing it properly among planes, we end-up failing the flip. It also takes care of enabling same watermark level for each

[Intel-gfx] [PATCH 05/11] drm/i915/skl: Fail the flip if no FB for WM calculation

Fail the flip if no FB is present but plane_state is set as visible. Above is not a valid combination so instead of continue fail the flip. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/intel_pm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

[Intel-gfx] [PATCH 01/11] drm/i915: fix naming of fixed_16_16 wrapper.

fixed_16_16_div_round_up(_u64), wrapper for fixed_16_16 division operation don't really round_up the result. Wrapper round_up only the fraction part of the result to make it 16-bit. This patch eliminates round_up keyword from the wrapper. Later patch will introduce the new wrapper to do

[Intel-gfx] [PATCH 03/11] drm/i915: Use fixed_16_16 wrapper for division operation

Don't use fixed_16_16 structure members directly, instead use wrapper to perform fixed_16_16 division operation. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/intel_pm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 04/11] drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed point

This patch make changes to calculate adjusted plane pixel rate & plane downscale amount using fixed_point functions available. This patch will give uniformity in code, & will help to avoid mixing of 32bit uint32_t variable for fixed-16.16 with fixed_16_16_t variables in later patch in the series.

[Intel-gfx] [PATCH 08/11] drm/i915/skl+: Watermark calculation cleanup

This patch cleanup/reorganises the watermark calculation functions. This patch also make use of already available macro "drm_atomic_crtc_state_for_each_plane_state" to walk through plane_state list instead of calculating plane_state in function itself. Now we iterate over WM levels in

[Intel-gfx] [PATCH 11/11] drm/i915/skl+: consider max supported plane pixel rate while scaling

A display resolution is only supported if it meets all the restrictions below for Maximum Pipe Pixel Rate. The display resolution must fit within the maximum pixel rate output from the pipe. Make sure that the display pipe is able to feed pixels at a rate required to support the desired

[Intel-gfx] [PATCH 07/11] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

DDB minimum requirement may exceed the allocated DDB for CRTC/Pipe. This patch make changes to fail the flip if minimum requirement for pipe exceeds the total ddb allocated to the pipe. Previously it succeeded but making alloc_size a negative value. Which will make later calculations for plane ddb

[Intel-gfx] [PATCH 06/11] drm/i915/skl+: no need to memset again

We are already doing memset of ddb structure at the begining of skl_allocate_pipe_ddb function, No need to again do a memset. Signed-off-by: Mahesh Kumar --- drivers/gpu/drm/i915/intel_pm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 05/11] drm/i915/skl: Fail the flip if no FB for WM calculation

Mahesh Kumar schreef op ma 08-05-2017 om 17:18 [+0530]: > Fail the flip if no FB is present but plane_state is set as visible. > Above is not a valid combination so instead of continue fail the > flip. Why is this patch necessary? drm_atomic_plane_check handles this. ~Maarten

Re: [Intel-gfx] [PATCH 05/11] drm/i915/skl: Fail the flip if no FB for WM calculation

Hi, On Monday 08 May 2017 05:18 PM, Lankhorst, Maarten wrote: Mahesh Kumar schreef op ma 08-05-2017 om 17:18 [+0530]: Fail the flip if no FB is present but plane_state is set as visible. Above is not a valid combination so instead of continue fail the flip. Why is this patch necessary?

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Make scratch register base and count flexible

On Mon, 08 May 2017, Joonas Lahtinen wrote: > PS. I personally don't like the enum typed bitfields, but that's an > another discussion (that's been had in the past). I'm with you on this one. It's semi-okay to define the bits as enums, but IMO a variable of an

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

On Mon, May 08, 2017 at 01:18:38PM +0300, Joonas Lahtinen wrote: > On ma, 2017-05-08 at 02:49 +, Li, Weinan Z wrote: > > Hi Joonas/Chris, do you have any comments? > > I've asked OCL team for this patch, they also agree to use available > > aperture size > > for max allocation buffer

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Restore GT performance in headless mode with DMC loaded (rev2)

== Series Details == Series: drm/i915: Restore GT performance in headless mode with DMC loaded (rev2) URL : https://patchwork.freedesktop.org/series/24017/ State : success == Summary == Series 24017v2 drm/i915: Restore GT performance in headless mode with DMC loaded

Re: [Intel-gfx] [PATCH 4/4] drm/i915/psr: Account for sink CRC raciness on some panels

On Mon, May 08, 2017 at 12:12:47PM +0300, Jani Nikula wrote: > On Sat, 06 May 2017, Jim Bride wrote: > > According to the eDP spec, when the count field in TEST_SINK_MISC > > increments then the six bytes of sink CRC information in the DPCD > > should be valid.

Re: [Intel-gfx] [PATCH v5 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

On Mon, 2017-05-08 at 10:49 -0700, Puthikorn Voravootivat wrote: > This is not related to brightness control. This calculation is used to > set the PWM frequency. > Frequency = 27 Mhz / (F * 2^ Pn) > > Lower Pn means higher value for F which mean more accuracy for this > calculation. I am not

Re: [Intel-gfx] [PATCH v5 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

Actually you are right. Sorry it's my mistake. I was focusing on make the actual frequency match the desired frequency as much as possible. But more granularity in backlight adjustment probably more important than that. Will submit new version of this patch to fix this. On Mon, May 8, 2017 at

Re: [Intel-gfx] [PATCH 4/4] drm/i915/psr: Account for sink CRC raciness on some panels

On Mon, 08 May 2017, Jim Bride wrote: > On Mon, May 08, 2017 at 12:12:47PM +0300, Jani Nikula wrote: >> On Sat, 06 May 2017, Jim Bride wrote: >> > According to the eDP spec, when the count field in TEST_SINK_MISC >> > increments then the six

Re: [Intel-gfx] [PATCH v7 02/20] drm/i915: Modify error handler for per engine hang recovery

On 4/29/2017 7:19 AM, Chris Wilson wrote: On Thu, Apr 27, 2017 at 04:12:42PM -0700, Michel Thierry wrote: From: Arun Siluvery This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this

Re: [Intel-gfx] [PATCH v5 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

This is not related to brightness control. This calculation is used to set the PWM frequency. Frequency = 27 Mhz / (F * 2^ Pn) Lower Pn means higher value for F which mean more accuracy for this calculation. On Sat, May 6, 2017 at 1:35 AM, Pandiyan, Dhinakaran < dhinakaran.pandi...@intel.com>

Re: [Intel-gfx] [PATCH v5 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote: > intel_dp_aux_backlight driver should check for the > DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver. > > Signed-off-by: Puthikorn Voravootivat > --- >

Re: [Intel-gfx] [PATCH v5 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

I added the option to choose to prioritized AUX or PWM before in last version of this patch set. But comment from Jani said that it is better to separate the patch. The option to prioritized the PWM in now in patch #4 On Mon, May 8, 2017 at 10:55 AM, Pandiyan, Dhinakaran <

Re: [Intel-gfx] [PATCH v5 2/9] drm/i915: Correctly enable backlight brightness adjustment via DPCD

On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote: > intel_dp_aux_enable_backlight() assumed that the register > BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01 > (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize. > > This patch fixed that by handling all cases of that

Re: [Intel-gfx] [PATCH v5 5/9] drm/i915: Set backlight mode before enable backlight

On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote: > We should set backlight mode register before set register to > enable the backlight. > Sounds reasonable, although I did not find anything in the spec. that says we should do this. If you've tested and it works, Reviewed-by:

Re: [Intel-gfx] [PATCH 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

On Fri, Apr 07, 2017 at 07:39:19PM +0300, Shashank Sharma wrote: > CEA-861-F specs defines new video modes to be used with > HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to > 1-107. > > Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now > to be able to parse new

[Intel-gfx] [PATCH 1/2] drm/i915/glk: Calculate high/low switch count for GLK

As per BSPEC, high/low switch count to be programmed in terms of byteclock using exit_zero_count and prep_count. For Geminilake exit/prep counts are already calculated in terms of byteclock. This patch calculates high/low switch count using counts value in byteclock, old calculation leads to

[Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK DSI

As per BSEPC, if device ready bit is '0' in enable IO sequence then its a cold boot/reset scenario eg: S3/S4 resume. In these conditions we need to program certain registers and prepare port from the middle of DSI enable sequence otherwise feature like S3/S4 doesn't work. Signed-off-by: Madhav

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

Hans de Goede writes: > HI, > > On 08-05-17 14:27, Chris Wilson wrote: >> On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote: >>> On some (Bay Trail) devices the LCD panel is mounted upside-down. >>> >>> This commit uses the code to read back the initial rotation

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

Regards Shashank On 5/8/2017 9:54 PM, Ville Syrjälä wrote: On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote: From: Jose Abreu HDMI 2.0 spec adds support for ycbcr420 subsampled output. CEA-861-F adds two new blocks in EDID, to provide information

Re: [Intel-gfx] [PATCH 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP

On Mon, May 08, 2017 at 11:41:25AM +0300, Jani Nikula wrote: > On Sat, 06 May 2017, Jim Bride wrote: > > This set of changes has some history to them. There were several attempts > > to add what was called "fast link training" to i915, which actually wasn't > > fast

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

HI, On 08-05-17 14:27, Chris Wilson wrote: On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote: On some (Bay Trail) devices the LCD panel is mounted upside-down. This commit uses the code to read back the initial rotation of the primary plane in get_initial_plane_config from Ville

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote: > From: Jose Abreu > > HDMI 2.0 spec adds support for ycbcr420 subsampled output. > CEA-861-F adds two new blocks in EDID, to provide information about > sink's support for ycbcr420 output. > > These new

Re: [Intel-gfx] [PATCH 02/11] drm/edid: Complete CEA modedb(VIC 1-107)

Regards Shashank On 5/8/2017 9:52 PM, Ville Syrjälä wrote: On Fri, Apr 07, 2017 at 07:39:19PM +0300, Shashank Sharma wrote: CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64

Re: [Intel-gfx] [PATCH 1/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.

On Mon, May 08, 2017 at 11:54:15AM +0300, Jani Nikula wrote: > On Sat, 06 May 2017, Jim Bride wrote: > > Some fixed resolution panels actually support more than one mode, > > with the only thing different being the refresh rate. Having this > > alternate mode available

Re: [Intel-gfx] [PATCH 04/11] drm: parse ycbcr420 vcb block

On Fri, Apr 07, 2017 at 07:39:21PM +0300, Shashank Sharma wrote: > HDMI 2.0 spec adds support for ycbcr420 subsampled output. > CEA-861-F adds two new blocks in EDID, to provide information about > sink's support for ycbcr420 output. > > One of these new blocks is: ycbcr420 vcb > - ycbcr420 video

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 5/8/2017 9:54 PM, Ville Syrjälä wrote: > > On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote: > >> From: Jose Abreu > >> > >> HDMI 2.0 spec adds support for

Re: [Intel-gfx] [PATCH 07/11] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

On Mon, 2017-05-08 at 17:18 +0530, Mahesh Kumar wrote: > DDB minimum requirement may exceed the allocated DDB for CRTC/Pipe. This > patch make changes to fail the flip if minimum requirement for pipe > exceeds the total ddb allocated to the pipe. > Previously it succeeded but making alloc_size a

Re: [Intel-gfx] [PATCH 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP

On Fri, 2017-05-05 at 14:02 -0700, Jim Bride wrote: > This set of changes has some history to them.  There were several > attempts > to add what was called "fast link training" to i915, which actually > wasn't > fast link training as per the DP spec.  These changes were > > 5fa836a9d859

[Intel-gfx] [PATCH] drm/vgem: Convert to a struct drm_device subclass

With Laura's introduction of the fake platform device for importing dmabuf, we add a second static that is logically tied to the vgem_device. Convert vgem over to using the struct drm_device subclassing, so that the platform device is stored inside its owner. Signed-off-by: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for Implement DDB algorithm and WM cleanup (rev2)

== Series Details == Series: Implement DDB algorithm and WM cleanup (rev2) URL : https://patchwork.freedesktop.org/series/20376/ State : success == Summary == Series 20376v2 Implement DDB algorithm and WM cleanup https://patchwork.freedesktop.org/api/1.0/series/20376/revisions/2/mbox/ Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/vgem: Convert to a struct drm_device subclass

== Series Details == Series: drm/vgem: Convert to a struct drm_device subclass URL : https://patchwork.freedesktop.org/series/24119/ State : success == Summary == Series 24119v1 drm/vgem: Convert to a struct drm_device subclass

Re: [Intel-gfx] [PATCH] drm/i915: Make vblank evade warnings optional

On 05/08/2017 01:25 AM, Daniel Vetter wrote: > On Sun, May 07, 2017 at 07:52:14PM -0600, Jens Axboe wrote: >> On 05/07/2017 11:56 AM, Daniel Vetter wrote: >>> On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote: On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote: >

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Deal with upside-down mounted LCD panels

On Sun, May 07, 2017 at 11:10:56AM +0200, Hans de Goede wrote: > On some (Bay Trail) devices the LCD panel is mounted upside-down. > > This commit uses the code to read back the initial rotation of the > primary plane in get_initial_plane_config from Ville Syrjala's > "drm/fb-helper: Inherit

Re: [Intel-gfx] [PATCH 4/4] drm/i915/psr: Account for sink CRC raciness on some panels

On Mon, May 08, 2017 at 09:05:08PM +0300, Jani Nikula wrote: > On Mon, 08 May 2017, Jim Bride wrote: > > On Mon, May 08, 2017 at 12:12:47PM +0300, Jani Nikula wrote: > >> On Sat, 06 May 2017, Jim Bride wrote: > >> > According to the eDP spec,

Re: [Intel-gfx] [PATCH v5 7/9] drm/i915: Restore brightness level in aux backlight driver

On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote: > Some panel will default to zero brightness when turning the > panel off and on again. This patch restores last brightness > level back when panel is turning back on. > > Signed-off-by: Puthikorn Voravootivat

Re: [Intel-gfx] [PATCH v5 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

On Mon, 2017-05-08 at 11:06 -0700, Puthikorn Voravootivat wrote: > I added the option to choose to prioritized AUX or PWM before in last > version of this patch set. > But comment from Jani said that it is better to separate the patch. > The option to prioritized the PWM in now in patch #4 You

Re: [Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

On Mon, 2017-05-08 at 16:45 -0700, Anusha Srivatsa wrote: > From: Rodrigo Vivi > > Split out BXT and CNP's setup_backlight(),enable_backlight(), > disable_backlight() and hz_to_pwm() into > two separate functions instead of reusing BXT function. > > Reuse set_backlight()

[Intel-gfx] [PATCH 2/6] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

From: Dhinakaran Pandiyan The first two bytes of PCI ID for CNP_LP PCH are the same as that of SPT_LP. We should really be looking at the first 9 bits instead of the first 8 to identify platforms, although this seems to have not caused any problems on earlier

[Intel-gfx] [PATCH 6/6] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

From: Rodrigo Vivi As for BXT, PP_DIVISOR was removed from CNP PCH and power cycle delay has been moved to PP_CONTROL. Cc: Jani Nikula Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_dp.c | 10 +- 1

[Intel-gfx] [PATCH 5/6] drm/i915/cnp: add CNP gmbus support

From: Rodrigo Vivi On CNP PCH based platforms the gmbus is on the south display that is on PCH. The existing implementation for previous platforms already covers the need for CNP expect for the pin pair configuration that follows similar definitions that we had on BXT.

[Intel-gfx] [PATCH 3/6] drm/i915/cnp: Get/set proper Raw clock frequency on CNP.

From: Rodrigo Vivi RAWCLK_FREQ register has changed for platforms with CNP+. [29:26] This field provides the denominator for the fractional part of the microsecond counter divider. The numerator is fixed at 1. Program this field to the denominator of

[Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

From: Rodrigo Vivi Split out BXT and CNP's setup_backlight(),enable_backlight(), disable_backlight() and hz_to_pwm() into two separate functions instead of reusing BXT function. Reuse set_backlight() and get_backlight() since they have no reference to the utility pin.

[Intel-gfx] [PATCH 0/6] Cannonpoint Enabling Patches

Rebased Rodrigo's patche series that enabled Cannonpoint support. https://patchwork.freedesktop.org/project/intel-gfx/patches/?submitter=13413==cnl= Dhinakaran Pandiyan (1): drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH Rodrigo Vivi (5): drm/i915/cnp: Introduce Cannonpoint PCH.

[Intel-gfx] [PATCH 1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

From: Rodrigo Vivi Most of south engine display that is in PCH is still the same as SPT and KBP, except for this key differences: - Backlight: Backlight programming changed in CNP PCH. - Panel Power: Sligh programming changed in CNP PCH. - GMBUS and GPIO: The pin mapping

Re: [Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

>-Original Message- >From: Pandiyan, Dhinakaran >Sent: Monday, May 8, 2017 5:10 PM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Vivi, Rodrigo ; >Nikula, Jani >Subject: Re: [Intel-gfx] [PATCH 4/6]