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.
> - get
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 patch is applied to
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 d
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 adds
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 ar
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 f
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 mod
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 just remove
the testcase itself? Accumulating unus
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 is
== 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 gem_e
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 redundant, why do we even have them? Can we just remov
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 i
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
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 1 -
> 1 file change
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
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 be
== 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
https://patchwork.freedesktop.org/api/1.0/series/26210/r
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 configur
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 Lahtinen
>> > ---
>> > drivers/gpu/drm/i915/i915
== 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
https://patchwork.freedesktop.org/api/1.
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 ++
>> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
>> 2 files changed, 27 i
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 go
== 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/
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 func
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.
> >> >
> >> > Signed-off-by: Matthew Auld
> >> > Cc:
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 th
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
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
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 +++--
1 file changed, 41 insertions(+), 12 deletions(-)
d
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 really appropriate there.
Signe
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 avoid any chances of missing the edg
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 do is clear the status
bits and
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 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git
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 i9xx_pipestat_irq_ack().
Signed-of
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.
Signed-off-by: Ville Syrjälä
---
drivers/gp
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 | 117 ++--
1 file changed, 1
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
1 file changed, 20 insertions(+), 16 deletions(
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 size of the
register. And indeed
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 for non-ring interrupts.
Signed-
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), reserved (gen4), render user inter
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 the IER gets restored.
This shoul
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ä
---
drivers/gpu/drm/i915/i915_ir
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 different way.
Signed-off-by:
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 changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.
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 +++--
1 file changed, 19 insertions(+), 18 deletio
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 the
IIR register is only 16 bits
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] https://bugs.freedesktop.org/show_b
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 a
== 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 gem_exec_susp
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 depends on the gen as follows:
>
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 a
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 clearing and whatnot that
> some of
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.
>
> Gen2 on the other hand has 16 bit i
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ä
Reviewed-by: Chris Wilson
-Chris
___
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ä
Reviewed-by: Chris Wilson
-Chris
___
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ä
Reviewed-by: Chris Wilson
-Chris
__
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ä
Reviewed-by: Chris Wilson
-Chris
_
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 irq_uninstall
> hooks even had them a
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 to contain all the
> bits, so it
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ä
Lgtm, but I haven't quite com
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, dead code (intel_check_page_fli
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 code.
>
> While at it s/u32 ii
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 results in potentially an extra
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 it.
>
> Cc: Alex Deucher
>
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
> actually read and clear the PIPES
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 shutting down
> the en
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 remain set we'll get another edge (a
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 up to the same quality standard
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 IER around acking the interrupts
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 in time. The gen2-4 irq code is r
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
dma_buf_unmap_attachment).
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 = drm_ge
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
dma_buf_unmap_attachment).
== 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 g
== 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/
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 mock test (as well) so that we can exercise
unlikely combinations of device support
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 pages correctly. Something like igt_ctx_exec,
but not quite so insane.
-Chris
__
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
> drm/i91
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
>
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
> https://patchwork.freede
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
== 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
https://patchwork.freedeskt
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: Clint Taylor
---
lib/i915_pciids.h | 8 +++-
1 file changed, 7 insertion
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
Reviewed-by: Clint Taylor
---
lib/i915_pciids.h | 10 ++
lib/intel_de
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
---
lib/i915_pciids.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --
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: Man
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
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 detect the PCH type. Currently w
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
Cc: Rodrigo Vivi
Signed-off-by: Anusha Sriv
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
Cc: Rodrigo Vivi
S
== 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
https://patchwork.freedesktop.o
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 parse the region info
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 h
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 V
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
---
drivers/gpu/drm/i915/i915_params
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 b
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
Cc: Ville Syrjala
Cc: Clint Taylor
---
driver
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 (Vi
== 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
https://patchwork.freedesktop.org/api/1.0/series/21086/revisions/12
Hi Dave,
I was hoping I wouldn't have to send a pull this week, but alas, we have a
regression fix to broken userspace. The issue was that we were sending stale
property
values from GETCONNECTOR after probing modes. The patch grabs the property
values after probe to ensure everything is cohesive.
== 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
https://patchwork.freedesktop.org/api/1.
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 ++
3
1 - 100 of 101 matches
Mail list logo
