Re: [Intel-gfx] [PATCH] lib/igt_draw: Add Y-tiling support

Hi Paulo, Could you plz review this patch in context of this series. https://patchwork.freedesktop.org/series/21467/ It should fix the issue that you highlighted. Thanks, Praveen On Friday 09 June 2017 03:48 PM, Praveen Paneri wrote: This patch adds Y-tiling support for igt_draw_rect

[Intel-gfx] [PATCH i-g-t] vc4: Test setting labels of BOs.

So far this test is basically making sure that we throw appropriate errors, and don't oops the kernel with silly inputs. Signed-off-by: Eric Anholt --- tests/Makefile.am | 2 ++ tests/Makefile.sources | 1 + tests/vc4_label_bo.c | 95

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/2] drm/i915/dp: Fix the t11_t12 panel power cycle delay from VBT read

== Series Details == Series: series starting with [v3,1/2] drm/i915/dp: Fix the t11_t12 panel power cycle delay from VBT read URL : https://patchwork.freedesktop.org/series/26245/ State : failure == Summary == Series 26245v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for Enhancement to intel_dp_aux_backlight driver (rev12)

== Series Details == Series: Enhancement to intel_dp_aux_backlight driver (rev12) URL : https://patchwork.freedesktop.org/series/21086/ State : success == Summary == Series 21086v12 Enhancement to intel_dp_aux_backlight driver

[Intel-gfx] [PATCH v3 1/2] drm/i915/dp: Fix the t11_t12 panel power cycle delay from VBT read

When we read the VBT t11_t12 value for panel power cycle delay, it is a zero based value so we need to 100ms to that. And then it needs to be multiplied by 10 to store it in 100usecs unit same as SW VBT. v3: * Add it as part of series v2: * Change the VBT value instead of HW readout and pp div

[Intel-gfx] [PATCH v3 2/2] drm/i915/dp: Remove -1/+1 from t11_t12 for Gen9_LP/CNP case

Now the VBT.seq->t11_t12 value adds 100ms to both Gen9_LP as well as non Gen9_LP cases so no need to special case and do -1 during HW readout and +1 during pp_div write for Gen9_LP/CNP case. Signed-off-by: Manasi Navare Suggested-by: Ville Syrjala

[Intel-gfx] [PATCH v12 3/3] drm/i915: Add option to support dynamic backlight via DPCD

This patch adds option to enable dynamic backlight for eDP panel that supports this feature via DPCD register and set minimum / maximum brightness to 0% and 100% of the normal brightness. Signed-off-by: Puthikorn Voravootivat Reviewed-by: Dhinakaran Pandiyan

[Intel-gfx] [PATCH v12 0/3] Enhancement to intel_dp_aux_backlight driver

This patch set contain 3 patches which are already reviewed by DK. Another 6 patches in previous version was already merged in v7 and v9. - First patch sets the PWM freqency to match data in panel vbt. - Next patch adds heuristic to determine whether we should use AUX or PWM pin to adjust panel

[Intel-gfx] [PATCH v12 2/3] drm/i915: Add heuristic to determine better way to adjust brightness

Add heuristic to decide that AUX or PWM pin should use for backlight brightness adjustment and modify i915 param description to have auto, force disable, and force enable. The heuristic to determine that using AUX pin is better than using PWM pin is that the panel support any of the feature list

[Intel-gfx] [PATCH v12 1/3] drm/i915: Set PWM divider to match desired frequency in vbt

Read desired PWM frequency from panel vbt and calculate the value for divider in DPCD address 0x724 and 0x728 to have as many bits as possible for PWM duty cyle for granularity of brightness adjustment while the frequency divisor is still within 25% of the desired value. Signed-off-by: Puthikorn

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

On Thu, 22 Jun 2017 10:30:15 +0200 Gerd Hoffmann wrote: > Hi, > > > > VFIO_DEVICE_FLAGS_GFX_DMABUF? > > > > After proposing these, I'm kind of questioning their purpose.  In the > > case of a GFX region, the user is going to learn that this is > > supported > > as they

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Fix the t11_t12 panel power cycle delay from VBT read

== Series Details == Series: drm/i915/dp: Fix the t11_t12 panel power cycle delay from VBT read URL : https://patchwork.freedesktop.org/series/26238/ State : success == Summary == Series 26238v1 drm/i915/dp: Fix the t11_t12 panel power cycle delay from VBT read

Re: [Intel-gfx] [PATCH] i965/CFL: Add PCI Ids for Coffee Lake.

On 17-06-22 10:42:45, Srivatsa, Anusha wrote: Coffee Lake has a gen9 graphics following KBL. From 3D perspective, CFL is a clone of KBL/SKL features. v2: Change commit message, correct alignment v3: Update IDs. v4: Initialize l3_banks, correct nomenclature Cc: Anuj Phogat

[Intel-gfx] [PATCH] i965/CFL: Add PCI Ids for Coffee Lake.

Coffee Lake has a gen9 graphics following KBL. From 3D perspective, CFL is a clone of KBL/SKL features. v2: Change commit message, correct alignment v3: Update IDs. v4: Initialize l3_banks, correct nomenclature Cc: Benjamin Widawsky Cc: Anuj Phogat

Re: [Intel-gfx] [PATCH 0/5] drm/i915: PCH detection cleanup

On Tue, Jun 20, 2017 at 04:03:05PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > During the recent discusison on the PCH detection details it was > suggested that we should just always use the top 9 bits of the > ISA/LPC bridge device ID to

Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Fix the t11_t12 panel power cycle delay from VBT read

On Thu, Jun 22, 2017 at 09:43:00AM -0700, Manasi Navare wrote: > When we read the VBT t11_t12 value for panel power cycle delay, > it is a zero based value so we need to 100ms to that. And then it > needs to be multiplied by 10 to store it in 100usecs unit same as > SW VBT. > > v2: > * Change the

[Intel-gfx] [PATCH v2] drm/i915/dp: Fix the t11_t12 panel power cycle delay from VBT read

When we read the VBT t11_t12 value for panel power cycle delay, it is a zero based value so we need to 100ms to that. And then it needs to be multiplied by 10 to store it in 100usecs unit same as SW VBT. v2: * Change the VBT value instead of HW readout and pp div (Ville Syrjala) Signed-off-by:

[Intel-gfx] [RESEND i-g-t 3/3] lib/cfl: Add PCI Ids for U SKU in CFl

From: anushasr Follow the spec and add ID for U SKU v2: Update IDs in accordance to the kernel commit: d29fe702c9cb682df99146d24d06e5455f043101 (Chris) Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa ---

[Intel-gfx] [RESEND i-g-t 2/3] lib/cfl: Add PCI IDs to H SKU in CFl

From: anushasr Follow the spec and add the ID for H SKU in CFL. v2: Update IDs following kernel commit: ccfd13215fd25a0e8c28221f3acc0dcaec11cd15 (Chris) Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa Reviewed-by:

[Intel-gfx] [RESEND i-g-t 1/3] lib/cfl: Add Coffeelake PCI IDs for S SKU.

From: anushasr Just following the spec and adding these extra IDs. v2: update IDs following the kernel commit: b056f8f3d6b900e8afd19f312719160346d263b4 (Chris) Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbdev: Check for existence of ifbdev->vma before operations

== Series Details == Series: drm/i915/fbdev: Check for existence of ifbdev->vma before operations URL : https://patchwork.freedesktop.org/series/26235/ State : success == Summary == Series 26235v1 drm/i915/fbdev: Check for existence of ifbdev->vma before operations

[Intel-gfx] [PATCH] drm/i915/fbdev: Check for existence of ifbdev->vma before operations

Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer flushes") adds a dependency to ifbdev->vma when flushing the framebufer, but the checks are only against the existence of the ifbdev->fb and not against ifbdev->vma. This leaves a window of opportunity where we may try to operate

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: pass the vma to insert_entries

Quoting Patchwork (2017-06-22 11:13:33) > == Series Details == > > Series: drm/i915: pass the vma to insert_entries > URL : https://patchwork.freedesktop.org/series/26208/ > State : success > > == Summary == > > Series 26208v1 drm/i915: pass the vma to insert_entries >

Re: [Intel-gfx] [PATCH v2 0/3] drm/i915: Misc improvements around module params

Quoting Michal Wajdeczko (2017-06-09 11:27:54) > Earlier RFC proposed to extend param macros with default values. > This series goes step further. > > v2: rename modparam instead of i915_params field > > Michal Wajdeczko (3): > drm/i915: Rename lvds_use_ssc modparam to panel_use_ssc >

Re: [Intel-gfx] [PATCH 00/12] fbdev helper locking rework and deferred setup

On Wed, Jun 21, 2017 at 08:28:03PM +0200, Daniel Vetter wrote: > Hi all, > > This is Thierry's deferred fbdev setup series, with the locking rework almost > entirely redone. The much wider scope is to get rid of drm_modeset_lock_all > calls for atomic drivers and remove users of the fairly nasty

Re: [Intel-gfx] [PATCH 15/19] drm/i915/selftests: basic huge page tests

Quoting Matthew Auld (2017-06-21 21:33:41) > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson I will also suggest that we combine this with some MI_STORE_DWORD tests to check the hw uses the

Re: [Intel-gfx] [PATCH 15/19] drm/i915/selftests: basic huge page tests

Quoting Matthew Auld (2017-06-21 21:33:41) > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson From my read through, we are only doing ppgtt operations. I think will be useful to try this as a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/vgem: Pin our pages for dmabuf exports (rev2)

== Series Details == Series: drm/vgem: Pin our pages for dmabuf exports (rev2) URL : https://patchwork.freedesktop.org/series/26222/ State : success == Summary == Series 26222v2 drm/vgem: Pin our pages for dmabuf exports https://patchwork.freedesktop.org/api/1.0/series/26222/revisions/2/mbox/

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/vgem: Pin our pages for dmabuf exports

== Series Details == Series: drm/vgem: Pin our pages for dmabuf exports URL : https://patchwork.freedesktop.org/series/26222/ State : success == Summary == Series 26222v1 drm/vgem: Pin our pages for dmabuf exports https://patchwork.freedesktop.org/api/1.0/series/26222/revisions/1/mbox/ Test

[Intel-gfx] [PATCH v2] drm/vgem: Pin our pages for dmabuf exports

When the caller maps their dmabuf and we return an sg_table, the caller doesn't expect the pages beneath that sg_table to vanish on a whim (i.e. under mempressure). The contract is that the pages are pinned for the duration of the mapping (from dma_buf_map_attachment() to

Re: [Intel-gfx] [PATCH] drm/vgem: Pin our pages for dmabuf exports

Quoting Chris Wilson (2017-06-22 14:30:08) > static void *vgem_prime_vmap(struct drm_gem_object *obj) > { > + struct drm_vgem_gem_object *bo = to_vgem_bo(obj); > long n_pages = obj->size >> PAGE_SHIFT; > struct page **pages; > void *addr; > > - pages =

[Intel-gfx] [PATCH] drm/vgem: Pin our pages for dmabuf exports

When the caller maps their dmabuf and we return an sg_table, the caller doesn't expect the pages beneath that sg_table to vanish on a whim (i.e. under mempressure). The contract is that the pages are pinned for the duration of the mapping (from dma_buf_map_attachment() to

Re: [Intel-gfx] [PATCH 00/17] drm/i915: Redo old gmch irq handling

On Thu, Jun 22, 2017 at 02:02:39PM +0100, Chris Wilson wrote: > Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:38) > > From: Ville Syrjälä > > > > Apparently we have some issues [1] on g4x which smells like irqs not getting > > delivered after some point

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Rewrite GMCH irq handlers to follow the VLV/CHV pattern

On Thu, Jun 22, 2017 at 02:00:49PM +0100, Chris Wilson wrote: > Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:55) > > From: Ville Syrjälä > > > > Eliminate the loops from the gen2-3 irq handlers by following the same > > trick used for VLV/CHV, ie. clear

Re: [Intel-gfx] [PATCH 00/17] drm/i915: Redo old gmch irq handling

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:38) > From: Ville Syrjälä > > Apparently we have some issues [1] on g4x which smells like irqs not getting > delivered after some point in time. The gen2-4 irq code is rather crusty > so I thought I'd bring it

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Rewrite GMCH irq handlers to follow the VLV/CHV pattern

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:55) > From: Ville Syrjälä > > Eliminate the loops from the gen2-3 irq handlers by following the same > trick used for VLV/CHV, ie. clear IER around acking the interrupts. > That way if some IIR bits still

Re: [Intel-gfx] [PATCH 13/13] drm/vblank: Unexport drm_vblank_cleanup

On Wed, Jun 21, 2017 at 4:28 AM, Daniel Vetter wrote: > There's no reason for drivers to call this, and all the ones I've > removed looked very fishy: > - Proper quiescenting of the vblank machinery should be done by > calling drm_crtc_vblank_off(), which is best done by

Re: [Intel-gfx] [PATCH 16/17] drm/i915: Extract PIPESTAT irq handling into separate functions

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:54) > From: Ville Syrjälä > > Extract the gen2-4 PIPESTAT irq handling into separate functions just > like we already do on VLV/CHV. > > We can share valleyview_pipestat_irq_ack() on all gmch platforms to >

Re: [Intel-gfx] [PATCH 01/13] drm/amd|radeon: Drop drm_vblank_cleanup

On Wed, Jun 21, 2017 at 4:28 AM, Daniel Vetter wrote: > Both drivers shut down all crtc beforehand already, which will shut up > any pending vblank (the only thing vblank_cleanup really does is > disable the disable timer). Hence we don't need this here and can > remove

Re: [Intel-gfx] [PATCH 15/17] drm/i915: Simplify the gen2-4 flip_mask handling

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:53) > From: Ville Syrjälä > > Replace the complicated "loop multiple times over IIR with different > flip_mask" logic with just clearing the relevant bit from IIR when > we actually handle the interrupt. This

Re: [Intel-gfx] [PATCH 14/17] drm/i915: Move the gen2-4 page flip handling code around

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:52) > From: Ville Syrjälä > > Move i8xx_handle_vblank() and i915_handle_vblank() to an earlier > location so that we can later collect all the PIPESTAT irq handling > code next to the VLV/CHV PIPESTAT handling

Re: [Intel-gfx] [PATCH 13/17] drm/i915: Consolidatte intel_check_page_flip() into intel_pipe_handle_vblank()

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:51) > From: Ville Syrjälä > > Almost all callers of intel_pipe_handle_vblank() immediately call > intel_check_page_flip() depending on the return value. Let's move > the call into the function itself. Bleugh,

Re: [Intel-gfx] [PATCH 12/17] drm/i915: Remove duplicated irq_preinstall/uninstall hooks

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:50) > From: Ville Syrjälä > > All the irq_preinstall and irq_uninstall hooks are now identical. Let's > just rename them all the irq_reset and remove the pointless duplicates. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 10/17] drm/i915: Gen3 HWSTAM is actually 32 bits

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:48) > From: Ville Syrjälä > > Bspec claims that HWSTAM is only 16 bits on gen3, but the other > interrupts registers are 32 bits and there are 18 valid interrupt > bits. Hence a 16 bit HWSTAM wouldn't be able

Re: [Intel-gfx] [PATCH 08/17] drm/i915: Remove NULL dev_priv checks from irq_uninstall

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:46) > From: Ville Syrjälä > > There should be no way to land in irq_uninstall without a > valid dev_priv. Let's kill off the remaining checks, which are > probably some kind of UMS leftovers. Not all the

Re: [Intel-gfx] [PATCH 07/17] drm/i915: Unify the appearance of gen3/4 irq_postistall hooks

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:45) > From: Ville Syrjälä > > Do the irq_mask/enable_mask setup in the same way on gen3/4, and also > reorder the steps to make the code more uniform. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 06/17] drm/i915: Eliminate PORT_HOTPLUG_EN setup from gen3/4 irq_postinstall

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:44) > From: Ville Syrjälä > > We've already cleared PORT_HOTPLUG_EN in the .irq_preinstall hook > so doing it again in the .irq_postinstall is pointless. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 05/17] drm/i915: Setup EMR first on all gen2-4

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:43) > From: Ville Syrjälä > > Unify the appaerance of the gen2-4 irq postinstall hooks a little > bit by doing the EMR setup first on all the platforms. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 04/17] drm/i915: Introduce GEN2_IRQ_RESET/INIT

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:42) > From: Ville Syrjälä > > Unify the appearance of the gen2 irq code with the gen3+ code by > introducing the GEN2_IRQ_RESET/INIT macros. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 02/17] drm/i915: s/GEN3/GEN5/

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:40) > From: Ville Syrjälä > > The GEN5_IRQ_RESET/INIT macros are perfectly suitable even for > gen3/4 hardware as those have 32 bit interrupt registers. Let's > rename the macros to reflect that fact. > >

Re: [Intel-gfx] [PATCH 01/17] drm/i915: Clear pipestat consistently

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:39) > From: Ville Syrjälä > > We have a lot of different ways of clearing the PIPESTAT registers. > Let's unify it all into one function. There's no magic in PIPESTAT > that would require any of the double

Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix the t11_t12 delay for non GEN 9 LP platforms at HW readout and HW write

On Wed, Jun 21, 2017 at 06:32:09PM -0700, Manasi Navare wrote: > On Wed, Jun 21, 2017 at 11:03:58PM +0300, Ville Syrjälä wrote: > > On Wed, Jun 21, 2017 at 12:37:43PM -0700, Manasi Navare wrote: > > > According to the eDP spec the minimum value for panel power cycle delay > > > (t11_t12) is 500ms

Re: [Intel-gfx] [PATCH 11/17] drm/i915: Clean up the HWSTAM mess

Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:49) > From: Ville Syrjälä > > Currently we're unmasking some random looking bits in HWSTAM > on gen3/4/5. The two bits we apparently unmask are 0 and 12, > and also bits 16-31 on gen4/5. > What those bits do

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Redo old gmch irq handling

== Series Details == Series: drm/i915: Redo old gmch irq handling URL : https://patchwork.freedesktop.org/series/26215/ State : success == Summary == Series 26215v1 drm/i915: Redo old gmch irq handling https://patchwork.freedesktop.org/api/1.0/series/26215/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915: Clear execbuf's vma backpointer upon release

Quoting Tvrtko Ursulin (2017-06-22 12:36:37) > > On 22/06/2017 11:47, Chris Wilson wrote: > > commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over the > > execobjects array") jiggled around the error handling and replace a test > > that we cleaned up properly after ourselves with an

Re: [Intel-gfx] [PATCH 00/17] drm/i915: Redo old gmch irq handling

On Thu, Jun 22, 2017 at 02:55:38PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Apparently we have some issues [1] on g4x which smells like irqs not getting > delivered after some point in time. The gen2-4 irq code is rather crusty [1]

[Intel-gfx] [PATCH 09/17] drm/i915: Mask everything in ring HWSTAM on gen6+ in ringbuffer mode

From: Ville Syrjälä The execlist code already masks everything in the ring HWSTAM, but the ringbuffer code doesn't. Let's go ahead and do that. Pre-gen6 platforms setup HWSTAM during irq setup already since there's just the one register, and it also contains bits

[Intel-gfx] [PATCH 11/17] drm/i915: Clean up the HWSTAM mess

From: Ville Syrjälä Currently we're unmasking some random looking bits in HWSTAM on gen3/4/5. The two bits we apparently unmask are 0 and 12, and also bits 16-31 on gen4/5. What those bits do depends on the gen as follows: bit 0: Breakpoint (gen2), ASLE (gen3),

[Intel-gfx] [PATCH 17/17] drm/i915: Rewrite GMCH irq handlers to follow the VLV/CHV pattern

From: Ville Syrjälä Eliminate the loops from the gen2-3 irq handlers by following the same trick used for VLV/CHV, ie. clear IER around acking the interrupts. That way if some IIR bits still remain set we'll get another edge (and thus another CPU interrupt) when

[Intel-gfx] [PATCH 08/17] drm/i915: Remove NULL dev_priv checks from irq_uninstall

From: Ville Syrjälä There should be no way to land in irq_uninstall without a valid dev_priv. Let's kill off the remaining checks, which are probably some kind of UMS leftovers. Not all the irq_uninstall hooks even had them anymore. Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH 13/17] drm/i915: Consolidatte intel_check_page_flip() into intel_pipe_handle_vblank()

From: Ville Syrjälä Almost all callers of intel_pipe_handle_vblank() immediately call intel_check_page_flip() depending on the return value. Let's move the call into the function itself. We'll just neeed to deal with the old gmch "flip pending" stuff in a slightly

[Intel-gfx] [PATCH 06/17] drm/i915: Eliminate PORT_HOTPLUG_EN setup from gen3/4 irq_postinstall

From: Ville Syrjälä We've already cleared PORT_HOTPLUG_EN in the .irq_preinstall hook so doing it again in the .irq_postinstall is pointless. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 6 -- 1 file

[Intel-gfx] [PATCH 05/17] drm/i915: Setup EMR first on all gen2-4

From: Ville Syrjälä Unify the appaerance of the gen2-4 irq postinstall hooks a little bit by doing the EMR setup first on all the platforms. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 37

[Intel-gfx] [PATCH 14/17] drm/i915: Move the gen2-4 page flip handling code around

From: Ville Syrjälä Move i8xx_handle_vblank() and i915_handle_vblank() to an earlier location so that we can later collect all the PIPESTAT irq handling code next to the VLV/CHV PIPESTAT handling code. While at it s/u32 iir/u16 iir/ for i8xx_handle_vblank() since

[Intel-gfx] [PATCH 12/17] drm/i915: Remove duplicated irq_preinstall/uninstall hooks

From: Ville Syrjälä All the irq_preinstall and irq_uninstall hooks are now identical. Let's just rename them all the irq_reset and remove the pointless duplicates. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c |

[Intel-gfx] [PATCH 07/17] drm/i915: Unify the appearance of gen3/4 irq_postistall hooks

From: Ville Syrjälä Do the irq_mask/enable_mask setup in the same way on gen3/4, and also reorder the steps to make the code more uniform. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 36

[Intel-gfx] [PATCH 10/17] drm/i915: Gen3 HWSTAM is actually 32 bits

From: Ville Syrjälä Bspec claims that HWSTAM is only 16 bits on gen3, but the other interrupts registers are 32 bits and there are 18 valid interrupt bits. Hence a 16 bit HWSTAM wouldn't be able to contain all the bits, so it seems the spec is incorrect about the

[Intel-gfx] [PATCH 16/17] drm/i915: Extract PIPESTAT irq handling into separate functions

From: Ville Syrjälä Extract the gen2-4 PIPESTAT irq handling into separate functions just like we already do on VLV/CHV. We can share valleyview_pipestat_irq_ack() on all gmch platforms to actually read and clear the PIPESTAT status bits, so let's rename it to

[Intel-gfx] [PATCH 15/17] drm/i915: Simplify the gen2-4 flip_mask handling

From: Ville Syrjälä Replace the complicated "loop multiple times over IIR with different flip_mask" logic with just clearing the relevant bit from IIR when we actually handle the interrupt. This results in potentially an extra IIR write, but so what.

[Intel-gfx] [PATCH 00/17] drm/i915: Redo old gmch irq handling

From: Ville Syrjälä Apparently we have some issues [1] on g4x which smells like irqs not getting delivered after some point in time. The gen2-4 irq code is rather crusty so I thought I'd bring it up to the same quality standards as the VLV/CHV irq code. And to

[Intel-gfx] [PATCH 01/17] drm/i915: Clear pipestat consistently

From: Ville Syrjälä We have a lot of different ways of clearing the PIPESTAT registers. Let's unify it all into one function. There's no magic in PIPESTAT that would require any of the double clearing and whatnot that some of the code tries to do. All we can really

[Intel-gfx] [PATCH 03/17] drm/i915: Use GEN3_IRQ_RESET/INIT on gen3/4

From: Ville Syrjälä Replace the manual IMR+IER+IIR write sequences with the appropriate GEN3_IRQ_RESET/INIT macro invocations in gen3/4. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 24 ++--

[Intel-gfx] [PATCH 02/17] drm/i915: s/GEN3/GEN5/

From: Ville Syrjälä The GEN5_IRQ_RESET/INIT macros are perfectly suitable even for gen3/4 hardware as those have 32 bit interrupt registers. Let's rename the macros to reflect that fact. Gen2 on the other hand has 16 bit interrupt registers so these macros aren't

[Intel-gfx] [PATCH 04/17] drm/i915: Introduce GEN2_IRQ_RESET/INIT

From: Ville Syrjälä Unify the appearance of the gen2 irq code with the gen3+ code by introducing the GEN2_IRQ_RESET/INIT macros. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_irq.c | 53

Re: [Intel-gfx] [PATCH] drm/i915: Check context status before looking up our obj/vma

On 21/06/2017 11:39, Chris Wilson wrote: Since we keep the context around across the slow lookup where we may drop the struct_mutex, we should double check that the context is still valid upon reacquisition. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH v2 13/14] drm: stm: remove dead code and pointless local lut storage

On 06/22/2017 08:06 AM, Peter Rosin wrote: > The redundant fb helper .load_lut is no longer used, and can not > work right without also providing the fb helpers .gamma_set and > .gamma_get thus rendering the code in this driver suspect. > Hi Peter, STM32 chipsets supports 8-bit CLUT mode but

Re: [Intel-gfx] [PATCH 10/19] drm/i915: support 1G pages for the 48b PPGTT

Quoting Matthew Auld (2017-06-22 12:07:55) > On 21 June 2017 at 23:51, Chris Wilson wrote: > > Quoting Chris Wilson (2017-06-21 22:49:07) > >> Quoting Matthew Auld (2017-06-21 21:33:36) > >> > Support inserting 1G gtt pages into the 48b PPGTT. > >> > > >> >

Re: [Intel-gfx] [PATCH] drm/i915: Clear execbuf's vma backpointer upon release

On 22/06/2017 11:47, Chris Wilson wrote: commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") jiggled around the error handling and replace a test that we cleaned up properly after ourselves with an assertion. That assertion failed because in the release

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Break modeset deadlocks on reset (rev4)

== Series Details == Series: drm/i915: Break modeset deadlocks on reset (rev4) URL : https://patchwork.freedesktop.org/series/26059/ State : success == Summary == Series 26059v4 drm/i915: Break modeset deadlocks on reset https://patchwork.freedesktop.org/api/1.0/series/26059/revisions/4/mbox/

[Intel-gfx] [PATCH i-g-t] Add support for subtest-specific documentation

The current documentation for tests is limited to a single string per test binary. This patch adds support for documenting individual subtests. The syntax for subtest documentation is: igt_subtest_documentation("Frob knobs to see if one of the " "crossbeams will

Re: [Intel-gfx] [PATCH 12/19] drm/i915: support 64K pages for the 48b PPGTT

On 21 June 2017 at 22:55, Chris Wilson wrote: > Quoting Matthew Auld (2017-06-21 21:33:38) >> Signed-off-by: Matthew Auld >> Cc: Joonas Lahtinen >> --- >> drivers/gpu/drm/i915/i915_gem_gtt.c | 26

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid keeping waitboost active for signaling threads

== Series Details == Series: drm/i915: Avoid keeping waitboost active for signaling threads URL : https://patchwork.freedesktop.org/series/26211/ State : success == Summary == Series 26211v1 drm/i915: Avoid keeping waitboost active for signaling threads

Re: [Intel-gfx] [PATCH 10/19] drm/i915: support 1G pages for the 48b PPGTT

On 21 June 2017 at 23:51, Chris Wilson wrote: > Quoting Chris Wilson (2017-06-21 22:49:07) >> Quoting Matthew Auld (2017-06-21 21:33:36) >> > Support inserting 1G gtt pages into the 48b PPGTT. >> > >> > Signed-off-by: Matthew Auld >> > Cc: Joonas

[Intel-gfx] [PATCH i-g-t] lib/igt_aux: Use provided autoresume delay for rtc wake

This stores the autoresume delay provided via igt_set_autoresume_delay for use during suspend via rtc wake scheduling. This delay was previously only used for pm_test suspendm while the function suggests it should be applied to all autoresume cases. There is also definitely a use case for

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Clear execbuf's vma backpointer upon release

== Series Details == Series: drm/i915: Clear execbuf's vma backpointer upon release URL : https://patchwork.freedesktop.org/series/26210/ State : success == Summary == Series 26210v1 drm/i915: Clear execbuf's vma backpointer upon release

[Intel-gfx] [PATCH v3] drm/i915: Break modeset deadlocks on reset

Trying to do a modeset from within a reset is fraught with danger. We can fall into a cyclic deadlock where the modeset is waiting on a previous modeset that is waiting on a request, and since the GPU hung that request completion is waiting on the reset. As modesetting doesn't allow its locks to

[Intel-gfx] [PATCH] drm/i915: Avoid keeping waitboost active for signaling threads

Once a client has requested a waitboost, we keep that waitboost active until all clients are no longer waiting. This is because we don't distinguish which waiter deserves the boost. However, with the advent of fence signaling, the signaler threads appear as waiters to the RPS interrupt handler. So

Re: [Intel-gfx] [PATCH 06/13] drm/mxsfb: Drop drm_vblank_cleanup

On 06/21/2017 10:28 AM, Daniel Vetter wrote: > Almost right but still racy, it's called before the interrupts are > uninstalled. So let's just drop it. > > Cc: Marek Vasut > Signed-off-by: Daniel Vetter Reviewed-by: Marek Vasut > --- >

[Intel-gfx] [PATCH] drm/i915: Clear execbuf's vma backpointer upon release

commit 2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array") jiggled around the error handling and replace a test that we cleaned up properly after ourselves with an assertion. That assertion failed because in the release function (moments after the assertion) we were

Re: [Intel-gfx] [RFC i-g-t 1/2] extended.testlist: Remove default and render engine test duplicates

On 22/06/2017 10:54, Daniel Vetter wrote: On Fri, Jun 16, 2017 at 12:55 PM, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Where there is both default and render for the same test, remove the former to save some execution time. If they are

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: pass the vma to insert_entries

== Series Details == Series: drm/i915: pass the vma to insert_entries URL : https://patchwork.freedesktop.org/series/26208/ State : success == Summary == Series 26208v1 drm/i915: pass the vma to insert_entries https://patchwork.freedesktop.org/api/1.0/series/26208/revisions/1/mbox/ Test

[Intel-gfx] [PATCH] drm/i915: pass the vma to insert_entries

The vma already contains most of the information we need for insertion. But also in preparation for supporting huge gtt pages, it would be useful to know the details of the vma, such that we can we can easily determine the page sizes we are allowed to use when inserting into the 48b PPGTT. This

Re: [Intel-gfx] [RFC i-g-t 1/2] extended.testlist: Remove default and render engine test duplicates

On Fri, Jun 16, 2017 at 12:55 PM, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Where there is both default and render for the same test, > remove the former to save some execution time. If they are redundant, why do we even have them? Can we

Re: [Intel-gfx] [RESEND-CI v4 09/15] drm: add helper functions for YCBCR output handling

Regards Shashank On 6/22/2017 12:35 PM, Daniel Vetter wrote: On Wed, Jun 21, 2017 at 04:04:06PM +0530, Shashank Sharma wrote: This patch adds set of helper functions for YCBCR HDMI output handling. These functions provide functionality like: - check if a given video mode is YCBCR 420 only

Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property

Thanks for the review, Daniel. My comments inline. Regards Shashank On 6/22/2017 12:44 PM, Daniel Vetter wrote: On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote: HDMI displays can support various output types, based on the color space and subsampling type. The possible outputs

Re: [Intel-gfx] [PATCH v9 5/7] vfio: Define vfio based dma-buf operations

Hi, > > VFIO_DEVICE_FLAGS_GFX_DMABUF? > > After proposing these, I'm kind of questioning their purpose.  In the > case of a GFX region, the user is going to learn that this is > supported > as they parse the region information and find the device specific > region identifying itself as a GFX

Re: [Intel-gfx] [PATCH RESEND v11 0/3] Enhancement to intel_dp_aux_backlight driver

On Mon, Jun 05, 2017 at 02:56:04PM -0700, Puthikorn Voravootivat wrote: > This patch set contain 3 patches which are already reviewed by DK. > Another 6 patches in previous version was already merged in v7 and v9. > - First patch sets the PWM freqency to match data in panel vbt. > - Next patch

Re: [Intel-gfx] [PATCH v5 7/7] drm: create hdmi output property

On Wed, Jun 21, 2017 at 04:04:13PM +0530, Shashank Sharma wrote: > HDMI displays can support various output types, based on > the color space and subsampling type. The possible > outputs from a HDMI 2.0 monitor could be: > - RGB > - YCBCR 444 > - YCBCR 422 > - YCBCR 420 > > This patch adds a

Re: [Intel-gfx] [PATCH 11/11] drm: remove unused and redundant callbacks

On Thu, 22 Jun 2017 08:37:55 +0200 Daniel Vetter wrote: > On Thu, Jun 22, 2017 at 12:34:36AM +0800, kbuild test robot wrote: > > Hi Peter, > > > > [auto build test ERROR on drm/drm-next] > > [also build test ERROR on next-20170621] > > [cannot apply to v4.12-rc6] > > [if your

Re: [Intel-gfx] [RESEND-CI v4 09/15] drm: add helper functions for YCBCR output handling

On Wed, Jun 21, 2017 at 04:04:06PM +0530, Shashank Sharma wrote: > This patch adds set of helper functions for YCBCR HDMI output > handling. These functions provide functionality like: > - check if a given video mode is YCBCR 420 only mode. > - check if a given video mode is YCBCR 420 mode. > -

  1   2   >