From: dell
Signed-off-by: Xiong Zhang
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_panel.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 47cef0e..f57a0b4 100644
--- a/driver
Only internal eDP, LVDS, DVI screen could set scalling mode, some
customers need to set scalling mode for external DP, HDMI, VGA
screen. Let's fulfill this.
bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90989
Signed-off-by: Xiong Zhang
---
drivers/gpu/drm/i915/intel_dp.c | 63 +
Signed-off-by: Xiong Zhang
---
drivers/gpu/drm/i915/intel_crt.c | 81 ++--
1 file changed, 77 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 521af2c..f8eedfc 100644
--- a/drivers/gpu/drm/i91
Signed-off-by: Xiong Zhang
---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_hdmi.c | 79 ---
2 files changed, 76 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f57a0b
Signed-off-by: Xiong Zhang
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_panel.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 47cef0e..f57a0b4 100644
--- a/drivers/gpu/drm/i91
From: Libin Yang
Add the set_ncts callback.
With the callback, audio driver can trigger
i915 driver to set the proper N/CTS
based on different sample rates.
Signed-off-by: Libin Yang
---
include/drm/i915_component.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/i915_compon
From: Libin Yang
When modeset occurs and the TMDS frequency is set to some
speical value, the N/CTS need to be set manually if audio
is playing.
Signed-off-by: Libin Yang
---
drivers/gpu/drm/i915/i915_reg.h| 6 ++
drivers/gpu/drm/i915/intel_audio.c | 42 +++
From: Libin Yang
Display audio may not work at some frequencies
with the HW provided N/CTS.
This patch sets the proper N value for the
given audio sample rate at the impacted frequencies.
At other frequencies, it will use the N/CTS value
which HW provides.
Signed-off-by: Libin Yang
---
driver
From: Libin Yang
On some Intel platforms, display audio need set N/CTS
manually at some TMDS frequencies.
Signed-off-by: Libin Yang
---
sound/pci/hda/patch_hdmi.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.
On 07/08/2015 11:13, Chris Wilson wrote:
On Fri, Aug 07, 2015 at 11:05:24AM +0100, Nick Hoath wrote:
Clean up lrc context init by:
- Move context initialisation in to i915_gem_init_hw
- Move one off initialisation for render ring to
i915_gem_validate_context
- Move default c
On Fri, 2015-08-07 at 12:36 +0100, Michel Thierry wrote:
> Hi Michał,
>
> Ben suggested having the set/clear in emit reloc as this is the only
> place mesa cares about these wa.
>
> But I see your point, this will be used not only by mesa, so we
> should
> have something that is good for all t
On Mon, 10 Aug 2015 09:32:11 +0200,
libin.y...@intel.com wrote:
>
> From: Libin Yang
>
> When modeset occurs and the TMDS frequency is set to some
> speical value, the N/CTS need to be set manually if audio
> is playing.
>
> Signed-off-by: Libin Yang
> ---
> drivers/gpu/drm/i915/i915_reg.h
On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote:
> Hi Daniel,
>
> That patch was already merged:
> http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.html
>
> For SKL, the above patch helped in getting the correct ISR bits set.
> One option is to enable the HDMI optim
On Thu, 06 Aug 2015, Mika Kuoppala wrote:
> If we encounter frequent problems with dp aux channel
> communications, we end up spamming the dmesg with the
> exact similar trace and status.
>
> Inject a new backtrace only if we have new information
> to share as otherwise we flush out all other impo
> -Original Message-
> From: Takashi Iwai [mailto:ti...@suse.de]
> Sent: Monday, August 10, 2015 4:04 PM
> To: Yang, Libin
> Cc: alsa-de...@alsa-project.org; intel-gfx@lists.freedesktop.org;
> daniel.vet...@ffwll.ch
> Subject: Re: [PATCH v4 4/4] drm/i915: set proper N/CTS in modeset
>
>
On Fri, Aug 07, 2015 at 10:04:47AM -0300, Paulo Zanoni wrote:
> 2015-08-06 18:33 GMT-03:00 Daniel Vetter :
> > This reverts commit 0b45b0746f45deea11670a8b2c949776bbbef55c.
> >
> > The point of testing for LAST_FLAG + 1 is to catch abi extensions -
> > despite our best efforts we really suck at pro
On 8/10/2015 1:38 PM, Daniel Vetter wrote:
On Mon, Aug 10, 2015 at 04:50:37AM +, Jindal, Sonika wrote:
Hi Daniel,
That patch was already merged:
http://lists.freedesktop.org/archives/intel-gfx/2015-July/071142.html
For SKL, the above patch helped in getting the correct ISR bits set.
One
The userptr worker allows for a slight race condition where upon there
may two or more threads calling get_user_pages for the same object. When
we have the array of pages, then we serialise the update of the object.
However, the worker should only overwrite the obj->userptr.work pointer
if and only
Michał Winiarski found a really evil way to trigger a struct_mutex
deadlock with userptr. He found that if he allocated a userptr bo and
then GTT mmaped another bo, or even itself, at the same address as the
userptr using MAP_FIXED, he could then cause a deadlock any time we then
had to invalidate
Whilst discussing possible ways to trigger an invalidate_range on a
userptr with an aliased GGTT mmapping (and so cause a struct_mutex
deadlock), the conclusion is that we can, and we must, prevent any
possible deadlock by avoiding taking the mutex at all during
invalidate_range. This has numerous
Hi Dave,
Sorry for interrupt.
I'm currently testing the MST audio with HSW.
Could you please help tell how I can say DP1.2 works?
I connect a DP1.2 monitor to HSW and a DP1.1 monitor to DP1.2 monitor output.
In this mode, can I make the 2 monitors show different contents? Thanks.
Regards,
Lib
Hi,
Thanks for the comments,
On 8/7/2015 11:46 PM, Kristian Høgsberg wrote:
On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry wrote:
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapl
On 08/08/2015 06:35, Ben Widawsky wrote:
On Fri, Aug 07, 2015 at 06:33:37PM +0100, Arun Siluvery wrote:
This WA doesn't have a name. According to the spec, driver need to reset
disable gather at set shader bit in per ctx WA batch. It is to be noted
that the default value is already '0' for this
->load is depracated, bus functionst are deprecated and everyone
should use drm_dev_alloc®ister.
So update the .tmpl (and pull a bunch of the overview docs into the
sourcecode to increase chances that it'll stay in sync in the future)
and add notes to functions which are deprecated. I didn't bothe
Spotted while reading code for random reasons.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 4a403eb90ded..4780b1924bef 100644
--- a/drivers/gpu/drm/drm
On Mon, Aug 03, 2015 at 01:09:11PM -0700, Jesse Barnes wrote:
> Looks like
>
> commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
> Author: Maarten Lankhorst
> Date: Mon Jun 15 12:33:53 2015 +0200
> drm/i915: Update less state during modeset.
>
> introduced the unconditional calling of disabl
On Wed, Jul 15, 2015 at 03:38:51PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
Chris,
After asking few people found that the simplest explanation and
plausible root cause
being that PORT D is set for both eDP and HDMI :). in which case the
proper fix is to
check in intel_dp_is_edp, if PORT D is again set for any other display
and return false
if that is the case
or
On Thu, Jul 09, 2015 at 11:32:34PM +0200, Daniel Vetter wrote:
> This function takes two locks, both of them the wrong ones. This
> wasn't an oversight from my fb locking rework since both patches
> landed in parallel. We really only need fb_lock when walking that
> list, since everything we can re
On Thu, Jul 09, 2015 at 11:32:35PM +0200, Daniel Vetter wrote:
> BUG_ON kills the driver, WARN_ON is much friendly. And usually nothing
> bad happens when the locking is lightly busted.
s/much friendly/much friendlier/, s/lightly/slightly/?
Otherwise:
Reviewed-by: Thierry Reding
signature.asc
On Mon, Aug 10, 2015 at 04:05:31PM +0530, Sivakumar Thulasimani wrote:
> Chris,
> After asking few people found that the simplest explanation and
> plausible root cause
> being that PORT D is set for both eDP and HDMI :). in which case the
> proper fix is to
> check in intel_dp_is_edp, if PORT
On Thu, Jul 09, 2015 at 11:32:37PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
On Thu, Jul 09, 2015 at 11:32:36PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
On Thu, Jul 09, 2015 at 11:32:39PM +0200, Daniel Vetter wrote:
> Looking up an obj, immediate dropping the acquired reference and then
> continuing to use it isn't how this is supposed to work. Fix this by
> holding a reference for the entire function.
>
> While at it stop grabbing dev->struct_mut
On Thu, Jul 09, 2015 at 11:32:38PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
On Thu, Jul 09, 2015 at 11:32:49PM +0200, Daniel Vetter wrote:
> It really doesn't protect anything which doesn't have other locks
> already. Also this is run from driver unload code so not much need for
> locks anyway.
>
> Same changes as for readone really.
s/radeone/radeon/
Otherwise:
Review
On Thu, Jul 09, 2015 at 11:32:40PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
On Thu, Jul 09, 2015 at 11:32:41PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
On Thu, Jul 09, 2015 at 11:32:42PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
On Mon, 10 Aug 2015, Jani Nikula wrote:
> On Thu, 06 Aug 2015, Mika Kuoppala wrote:
>> If we encounter frequent problems with dp aux channel
>> communications, we end up spamming the dmesg with the
>> exact similar trace and status.
>>
>> Inject a new backtrace only if we have new information
>>
On Thu, Jul 09, 2015 at 11:32:43PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
On Thu, Jul 09, 2015 at 11:32:44PM +0200, Daniel Vetter wrote:
> It doesn't protect anything at all. fbdev helper state is all
> protected by modeset locks, and nouveau bo state is taken care of by
> ttm. There's also nothing else grabbing struct_mutex that might need
> to coordinate with this code
On Thu, Jul 09, 2015 at 11:32:45PM +0200, Daniel Vetter wrote:
> This is only called in driver load/unload paths, no need to grab any
> locks at all. Also, ttm takes care of itself anyway.
>
> Cc: Ben Skeggs
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 --
>
On Thu, Jul 09, 2015 at 11:32:46PM +0200, Daniel Vetter wrote:
> It really doesn't protect anything which doesn't have other locks
> already. It also doesn't seem to be wired up into the driver unload
> code fwiw, but that's a different issue.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu
On Thu, Jul 09, 2015 at 11:32:47PM +0200, Daniel Vetter wrote:
> It really doesn't protect anything which doesn't have other locks
> already. Also this is run from driver unload code so not much need for
> locks anyway.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Signed-off-by: Daniel Vetter
On Thu, Jul 09, 2015 at 11:32:48PM +0200, Daniel Vetter wrote:
> We already grab 2 device-global locks (write-sema rdev->pm.mclk_lock
> and rdev->ring_lock), adding another global mutex won't serialize this
> code more. And since there's really nothing interesting that gets
> protected in radeon by
On Thu, Jul 09, 2015 at 11:32:50PM +0200, Daniel Vetter wrote:
> Similar to radeon, except that amdgpu doesn't even use struct_mutex to
> protect anything like the shared z buffer (sane gpu architecture,
> yay!). And the code already grabs the globa adev->ring_lock, so this
> code can't race with i
On Thu, Jul 09, 2015 at 11:32:43PM +0200, Daniel Vetter wrote:
> Since David Herrmann's mmap vma manager rework we don't need to grab
> dev->struct_mutex any more to prevent races when looking up the mmap
> offset. Drop it and instead don't forget to use the unref_unlocked
> variant (since the drm
On Mon, Aug 10, 2015 at 12:30:21PM +0200, Thierry Reding wrote:
> On Wed, Jul 15, 2015 at 03:38:51PM +0200, Daniel Vetter wrote:
> > Since David Herrmann's mmap vma manager rework we don't need to grab
> > dev->struct_mutex any more to prevent races when looking up the mmap
> > offset. Drop it and
On Thu, Jul 09, 2015 at 11:32:33PM +0200, Daniel Vetter wrote:
> Doesn't really add anything which can't be figured out through
> proc files. And more clearly separates the new gem mmap handling
> code from the old drm maps mmap handling code, which is surely a
> good thing.
>
> Cc: Martin Peres
Instead of our own duplicated one. This fixes a bug in the driver
unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
try to unregister the nonexistent fbdev drm_framebuffer.
Cc: Archit Taneja
Cc: Maarten Lankhorst
Reported-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
--
On Mon, 10 Aug 2015, Sivakumar Thulasimani
wrote:
> Reviewed-by: Sivakumar Thulasimani
>
> On 8/10/2015 10:35 AM, Sonika Jindal wrote:
>> With HPD support added for all ports including PORT_A, setting hpd_pin will
>> result in enabling of hpd to edp as well. There is no need to enable HPD on
>>
On Thu, Jul 09, 2015 at 11:32:32PM +0200, Daniel Vetter wrote:
> Hi all,
>
> I wanted to take another look at struct_mutex usage in modern (gem) drivers
> and
> noticed that for a fair lot we're very to be completely struct_mutex free.
>
> This pile here is the the simple part, which mostly just
On Mon, Aug 10, 2015 at 01:31:42PM +0200, Daniel Vetter wrote:
> On Mon, Aug 10, 2015 at 12:30:21PM +0200, Thierry Reding wrote:
> > On Wed, Jul 15, 2015 at 03:38:51PM +0200, Daniel Vetter wrote:
> > > Since David Herrmann's mmap vma manager rework we don't need to grab
> > > dev->struct_mutex any
On 8/10/2015 5:07 PM, Jani Nikula wrote:
On Mon, 10 Aug 2015, Sivakumar Thulasimani
wrote:
Reviewed-by: Sivakumar Thulasimani
On 8/10/2015 10:35 AM, Sonika Jindal wrote:
With HPD support added for all ports including PORT_A, setting hpd_pin will
result in enabling of hpd to edp as well. T
On Mon, Aug 10, 2015 at 12:42:30PM +0200, Thierry Reding wrote:
> On Thu, Jul 09, 2015 at 11:32:35PM +0200, Daniel Vetter wrote:
> > BUG_ON kills the driver, WARN_ON is much friendly. And usually nothing
> > bad happens when the locking is lightly busted.
>
> s/much friendly/much friendlier/, s/li
On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> From: Libin Yang
>
> Add the set_ncts callback.
>
> With the callback, audio driver can trigger
> i915 driver to set the proper N/CTS
> based on different sample rates.
>
> Signed-off-by: Libin Yang
> ---
> include/drm/i915_component.h | 2 ++
>
On Mon, Aug 10, 2015 at 01:34:08PM +0200, Daniel Vetter wrote:
> Instead of our own duplicated one. This fixes a bug in the driver
> unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
> try to unregister the nonexistent fbdev drm_framebuffer.
>
> Cc: Archit Taneja
> Cc: Maarten
On Mon, Aug 10, 2015 at 01:35:58PM +0200, Thierry Reding wrote:
> On Thu, Jul 09, 2015 at 11:32:32PM +0200, Daniel Vetter wrote:
> > Hi all,
> >
> > I wanted to take another look at struct_mutex usage in modern (gem) drivers
> > and
> > noticed that for a fair lot we're very to be completely stru
On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> From: Libin Yang
>
> Display audio may not work at some frequencies
> with the HW provided N/CTS.
>
> This patch sets the proper N value for the
> given audio sample rate at the impacted frequencies.
> At other frequencies, it will use the N/CTS v
On Mon, Aug 10, 2015 at 12:53:23PM +0100, Chris Wilson wrote:
> On Mon, Aug 10, 2015 at 01:35:58PM +0200, Thierry Reding wrote:
> > On Thu, Jul 09, 2015 at 11:32:32PM +0200, Daniel Vetter wrote:
> > > Hi all,
> > >
> > > I wanted to take another look at struct_mutex usage in modern (gem)
> > > dr
On Mon, Aug 10, 2015 at 11:55:37AM +0200, Daniel Vetter wrote:
> Spotted while reading code for random reasons.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/d
On Mon, Aug 10, 2015 at 11:55:38AM +0200, Daniel Vetter wrote:
> ->load is depracated, bus functionst are deprecated and everyone
> should use drm_dev_alloc®ister.
Why would you want to deprecated ->load()? Even if you use
drm_dev_alloc() and drm_dev_register(), there's still use for ->load()
beca
On Mon, Aug 10, 2015 at 01:35:58PM +0200, Thierry Reding wrote:
> On Thu, Jul 09, 2015 at 11:32:32PM +0200, Daniel Vetter wrote:
> > Hi all,
> >
> > I wanted to take another look at struct_mutex usage in modern (gem) drivers
> > and
> > noticed that for a fair lot we're very to be completely stru
On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> From: Libin Yang
>
> On some Intel platforms, display audio need set N/CTS
> manually at some TMDS frequencies.
>
> Signed-off-by: Libin Yang
> ---
> sound/pci/hda/patch_hdmi.c | 23 +++
> 1 file changed, 23 insertions(+)
>
>
On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> From: Libin Yang
>
> When modeset occurs and the TMDS frequency is set to some
> speical value, the N/CTS need to be set manually if audio
> is playing.
When modeset occurs, we disable everything, and then re-enable
everything, and notify the aud
On Mon, Aug 10, 2015 at 01:59:07PM +0200, Thierry Reding wrote:
> On Mon, Aug 10, 2015 at 11:55:38AM +0200, Daniel Vetter wrote:
> > ->load is depracated, bus functionst are deprecated and everyone
> > should use drm_dev_alloc®ister.
>
> Why would you want to deprecated ->load()? Even if you use
>
On Mon, Aug 10, 2015 at 01:57:21PM +0200, Thierry Reding wrote:
> On Mon, Aug 10, 2015 at 11:55:37AM +0200, Daniel Vetter wrote:
> > Spotted while reading code for random reasons.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_edid.c | 2 +-
> > 1 file changed, 1 insertion(
On Mon, Aug 10, 2015 at 01:48:53PM +0200, Thierry Reding wrote:
> On Mon, Aug 10, 2015 at 01:34:08PM +0200, Daniel Vetter wrote:
> > Instead of our own duplicated one. This fixes a bug in the driver
> > unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
> > try to unregister the n
On Fri, Jul 31, 2015 at 03:41:15PM +0200, Daniel Vetter wrote:
> On Fri, Jul 31, 2015 at 10:34:43AM +0200, Maarten Lankhorst wrote:
> > Hey,
> >
> > Op 29-07-15 om 12:51 schreef Daniel Vetter:
> > > In
> > >
> > > commit 6f75cea66c8dd043ced282016b21a639af176642
> > > Author: Daniel Vetter
> > > D
On Thu, Aug 06, 2015 at 03:06:40PM +0200, Daniel Vetter wrote:
> We want to make sure that no one tries to acquire more locks and
> states, and ww mutexes provide debug facilities for that. So use them.
>
> v2: Only call acquire_done when ->atomic_check was successful to avoid
> falling over an -E
On Mon, 10 Aug 2015, Sivakumar Thulasimani
wrote:
> On 8/10/2015 5:07 PM, Jani Nikula wrote:
>> On Mon, 10 Aug 2015, Sivakumar Thulasimani
>> wrote:
>>> Reviewed-by: Sivakumar Thulasimani
>>>
>>> On 8/10/2015 10:35 AM, Sonika Jindal wrote:
With HPD support added for all ports including PO
On Mon, 10 Aug 2015, libin.y...@intel.com wrote:
> From: Libin Yang
>
> Display audio may not work at some frequencies
> with the HW provided N/CTS.
>
> This patch sets the proper N value for the
> given audio sample rate at the impacted frequencies.
> At other frequencies, it will use the N/CTS v
On Mon, Aug 10, 2015 at 03:14:36PM +0300, Jani Nikula wrote:
> On Mon, 10 Aug 2015, Sivakumar Thulasimani
> wrote:
> > On 8/10/2015 5:07 PM, Jani Nikula wrote:
> >> On Mon, 10 Aug 2015, Sivakumar Thulasimani
> >> wrote:
> >>> Reviewed-by: Sivakumar Thulasimani
> >>>
> >>> On 8/10/2015 10:35 AM
On 8/10/2015 5:44 PM, Jani Nikula wrote:
On Mon, 10 Aug 2015, Sivakumar Thulasimani
wrote:
On 8/10/2015 5:07 PM, Jani Nikula wrote:
On Mon, 10 Aug 2015, Sivakumar Thulasimani
wrote:
Reviewed-by: Sivakumar Thulasimani
On 8/10/2015 10:35 AM, Sonika Jindal wrote:
With HPD support added f
On Mon, Aug 10, 2015 at 02:07:49PM +0200, Daniel Vetter wrote:
> On Mon, Aug 10, 2015 at 01:59:07PM +0200, Thierry Reding wrote:
> > On Mon, Aug 10, 2015 at 11:55:38AM +0200, Daniel Vetter wrote:
> > > ->load is depracated, bus functionst are deprecated and everyone
> > > should use drm_dev_alloc®i
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6910
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -2
On Thu, Aug 06, 2015 at 02:33:31PM -0700, Jesse Barnes wrote:
> On 08/06/2015 02:30 PM, Daniel Vetter wrote:
> > On Fri, May 29, 2015 at 09:52:52AM +0200, Daniel Vetter wrote:
> >> On Thu, May 28, 2015 at 05:53:17PM +0300, David Weinehall wrote:
> >>> On Wed, May 27, 2015 at 01:32:10PM +0200, Danie
On Thu, Aug 06, 2015 at 11:30:00PM +0200, Daniel Vetter wrote:
[snip]
> Update version of this patch is still missing. I'll need to revert the
> kernel side if this one doesn't show up soonish.
>
> Also you're breaking the invalid-flags testcase (did you bother to run
> them all and check for regr
On Mon, Aug 10, 2015 at 02:34:18PM +0200, Thierry Reding wrote:
> On Mon, Aug 10, 2015 at 02:07:49PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 10, 2015 at 01:59:07PM +0200, Thierry Reding wrote:
> > > On Mon, Aug 10, 2015 at 11:55:38AM +0200, Daniel Vetter wrote:
> > > > ->load is depracated, bus
On Mon, Jul 13, 2015 at 11:44:44AM +0530, Sivakumar Thulasimani wrote:
>
>
> On 6/29/2015 5:55 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
> > chicken bits to propagate the pixel multiplier from DPLL_
Chris Wilson writes:
> If we encounter an allocation failure during ppggt creation (trivial
> even with 16Gib+ RAM!), we need to remove the dead context from the
> fpriv->context_idr along with the references.
>
> gem_exec_ctx: page allocation failure: order:0, mode:0x8004
> CPU: 3 PID: 27272 Com
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6911
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
I started digging this when I noticed that the BDW code was just
reserving 1mb by coincidence since it was reading reserved fields.
Then I noticed we didn't have any values set for SNB and earlier, and
that the HSW sizes were wrong. After that, I noticed that the reserved
area has a specific start,
On Mon, Aug 10, 2015 at 02:57:32PM -0300, Paulo Zanoni wrote:
> I started digging this when I noticed that the BDW code was just
> reserving 1mb by coincidence since it was reading reserved fields.
> Then I noticed we didn't have any values set for SNB and earlier, and
> that the HSW sizes were wro
I believe this function could be added along with the next patch that is
the first to use it...
Or it would be good to have a good commit message explaining why this
function is needed and what is be used for...
more bikeshedings inline:
On Mon, Aug 10, 2015 at 12:39 AM Xiong Zhang
wrote:
> Sig
If the set of pages is being imported from another device, we cannot
assume that it is fully coherent with the CPU cache, so mark it as such.
However, if the source is the shared memory vgem allocator, we could
treat the buffer as being cached (so long as all parties agree in the
case the same buff
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6912
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
On Mon, Aug 10, 2015 at 2:21 AM, Michel Thierry
wrote:
> Hi,
>
> Thanks for the comments,
>
> On 8/7/2015 11:46 PM, Kristian Høgsberg wrote:
>>
>> On Fri, Aug 7, 2015 at 2:45 AM, Michel Thierry
>> wrote:
>>>
>>> Gen8+ supports 48-bit virtual addresses, but some objects must always be
>>> allocate
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6923
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -2
Hi Raymond,
From: Raymond Yau [mailto:superquad.vort...@gmail.com]
Sent: Monday, August 10, 2015 12:23 PM
To: Yang, Libin
Cc: alsa-de...@alsa-project.org; Takashi Iwai; Lin, Mengdong;
intel-gfx@lists.freedesktop.org
Subject: RE: [alsa-devel] [PATCH 3/4] ALSA: hda - display audio call ncts
callba
Hi Jani,
Thanks for reviewing, please see my comments
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, August 10, 2015 7:46 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffw
Hi Jani,
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, August 10, 2015 8:00 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH v2 2/
Hi Jani,
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, August 10, 2015 8:03 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH v3 3/4
Hi Jani,
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, August 10, 2015 8:17 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH v2 2/4
Hi Jani,
Thanks for careful reviewing for all the patches, please
see my comments.
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, August 10, 2015 8:10 PM
> To: Yang, Libin; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freed
I replied to Daniel last time. Pasting it on mailing list as well:
"Yes this is tested on android with HW tracking. Not sure about enabling by
default part. But this patch will be anyways required.
Regards,
Sonika"
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] O
Hi Mika/Dave/Michel,
I saw the patch of using LRI for root pointer update has been merged to
drm-intel. When we consider i915 driver to run inside a virtual machine, e.g.
with XenGT, we may still need Mika's this patch like below:
"
if (intel_vgpu_active(ppgtt->base.dev))
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6929
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
> -Original Message-
> From: Yang, Libin
> Sent: Tuesday, August 11, 2015 10:41 AM
> To: 'Jani Nikula'; alsa-de...@alsa-project.org; ti...@suse.de; intel-
> g...@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: RE: [Intel-gfx] [PATCH v2 1/4] drm/i915: Add audio set_ncts
> callback
>
1 - 100 of 103 matches
Mail list logo
