On Thu, Oct 18, 2018 at 05:25:58PM +0300, Imre Deak wrote:
> In order to ensure that our system suspend and resume callbacks are
> called in the correct order wrt. those of the HDA driver add a device
> link to the HDA driver during audio component binding time. With i915 as
> the supplier and HDA
On Fri, 2018-10-19 at 14:02 -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> > When a PSR error happens sink also update the link status values
> > while source do not retrain link as required in the PSR exit
> > sequence.
> > So in the short pul
On Thu, 2018-10-18 at 15:16 -0700, Manasi Navare wrote:
> In case of Legacy DP connector on TypeC port, the
> flex IO DPMLE register is set to number of lanes configured
> by the display driver which will be programmed into DDI_BUF_CTL
> PORT_WIDTH_SELECTION.
> This needs to be programmed before en
On Thu, 2018-10-18 at 15:16 -0700, Manasi Navare wrote:
> This patch fixes the macros used for defining the DFLEXDPMLE
> register bit fields. This accounts for changes in the spec.
>
> Fixes: a2bc69a1a9d6 ("drm/i915/icl: Add register definition for
> DFLEXDPMLE")
> Cc: Animesh Manna
> Cc: Paulo Z
Thanks for the review.
Pushed to drm-misc
Manasi
On Tue, Oct 09, 2018 at 04:43:51PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 08, 2018 at 05:23:51PM -0700, Manasi Navare wrote:
> > VESA eDP 1.4 specification has separate fields defined in
> > EDP_DPCD_REV for eDP 1.4a and 1.4b eDP revisions.
> >
On Fri, 2018-10-19 at 16:14 -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> > While PSR is active hardware will do aux transactions by it self to
> > wakeup sink to receive a new frame when necessary. If that
> > transaction is not acked by sink
On Fri, 2018-10-19 at 13:42 -0700, Dhinakaran Pandiyan wrote:
> On Wednesday, October 10, 2018 5:41:20 PM PDT José Roberto de Souza
> wrote:
> > It should always wait for idle state when disabling PSR because PSR
> > could be inactive due a call to intel_psr_exit() and while PSR is
> > still being
On Thu, 2018-10-11 at 16:21 +0300, Ville Syrjälä wrote:
> On Wed, Oct 10, 2018 at 05:41:23PM -0700, José Roberto de Souza
> wrote:
> > Some eDP panels do not set a valid sink count value and even for
> > the
> > ones that sets is should always be one for eDP, that is why it is
> > not
> > cached in
On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> While PSR is active hardware will do aux transactions by it self to
> wakeup sink to receive a new frame when necessary. If that
> transaction is not acked by sink, hardware will trigger this
> interruption.
>
> So let's disable PSR
On Fri, Oct 19, 2018 at 01:29:05PM -0700, Manasi Navare wrote:
> On Fri, Oct 19, 2018 at 10:58:29PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 19, 2018 at 12:24:43PM -0700, Manasi Navare wrote:
> > > On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
> > > > On Mon, Oct 15, 2018 at 02:
On Thu, Oct 18, 2018 at 08:02:14PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 05, 2018 at 04:23:02PM -0700, Manasi Navare wrote:
> > Display Stream Splitter registers need to be programmed to enable
> > the joiner if two DSC engines are used and also to enable
> > the left and the right DSC engines.
Now that we have the number of ddi ports information available
let's use it instead of that ugly platform macro.
v2: - Don't override platform info (Jani) But use platform info (Daniel)
- Don't use ddi_ports when it doesn't make sense (Lucas)
- Add a comment to let clear that port E is fus
From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of Manasi
Navare [manasi.d.nav...@intel.com]
Sent: Thursday, October 18, 2018 3:16 PM
To: intel-gfx@lists.freedesktop.org
Cc: Zanoni, Paulo R
Subject: [Intel-gfx] [PATCH 1/2] drm/i915/icl:
On Fri, Oct 19, 2018 at 02:16:57PM -0700, Daniele Ceraolo Spurio wrote:
> commit e346a991f42c ("drm/i915/guc: drop negative doorbell alloc
> selftest") removed the negative case from the selftest and left no
> code between the goto from the positive case of the test and the label
> itself, so we ca
commit e346a991f42c ("drm/i915/guc: drop negative doorbell alloc
selftest") removed the negative case from the selftest and left no
code between the goto from the positive case of the test and the label
itself, so we can get rid of it.
Reported-by: Lucas De Marchi
Cc: Lucas De Marchi
Cc: Michal
On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> When a PSR error happens sink also update the link status values
> while source do not retrain link as required in the PSR exit
> sequence.
> So in the short pulse handling it was returning earlier and doing a
> full detection and at
On Wed, 2018-10-10 at 17:41 -0700, José Roberto de Souza wrote:
> In the past we had hooks to configure HW for VLV/CHV too, in the drop
> of VLV/CHV support the intel_psr_disable_source() code was not moved
> to the caller, so doing it here.
>
> Suggested-by: Dhinakaran Pandiyan
Reviewed-by: Dhi
On Fri, 2018-10-19 at 13:42 -0700, Dhinakaran Pandiyan wrote:
> On Wednesday, October 10, 2018 5:41:20 PM PDT José Roberto de Souza
> wrote:
> > It should always wait for idle state when disabling PSR because PSR
> > could be inactive due a call to intel_psr_exit() and while PSR is
> > still being
>-Original Message-
>From: Navare, Manasi D
>Sent: Friday, October 19, 2018 1:29 PM
>To: Ville Syrjälä
>Cc: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org; Singh, Gaurav K ; Jani
>Nikula
>Subject: Re: [v2 5/6] i915/dp/fec: Configure the Forward Error Correction bits.
>
>On Fri, O
On Wednesday, October 10, 2018 5:41:20 PM PDT José Roberto de Souza wrote:
> It should always wait for idle state when disabling PSR because PSR
> could be inactive due a call to intel_psr_exit() and while PSR is
> still being disabled asynchronously userspace could change the
> modeset causing a c
On Fri, Oct 19, 2018 at 09:08:15PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-10-19 17:55:02)
> > From: Ville Syrjälä
> >
> > Once we've switched to using the swcursor (possibly
> > due to the cursor ioctl failing) we currently keep
> > using the swcursor until the modeset.
> >
> >
On Wednesday, October 10, 2018 5:41:19 PM PDT José Roberto de Souza wrote:
> Both functions have the same code to disable PSR, so let's reuse that
> code instead of duplicate.
>
> Suggested-by: Dhinakaran Pandiyan
> Cc: Dhinakaran Pandiyan
Reviewed-by: Dhinakaran Pandiyan
> Signed-off-by: José
On Fri, Oct 19, 2018 at 10:58:29PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 19, 2018 at 12:24:43PM -0700, Manasi Navare wrote:
> > On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
> > > On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> > > > If FEC is supported, the
Instead of a simple bool that shows if we have ddi ports
or not, let's highlight the number of ddi ports.
So we can use this information to determine the code
path instead of using platforms codenames.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/
Now that we have the number of ddi ports information available
let's use it instead of that ugly platform macro.
v2: - Don't override platform info (Jani) But use platform info (Daniel)
- Don't use ddi_ports when it doesn't make sense (Lucas)
- Add a comment to let clear that port E is fus
After all, no Cannonlake has HPD_PORT_F, even the skus with port F.
Also we will only reach this case if PORT_F is already there in
use.
So let's use IS_CANNONLAKE directly here and avoid the ugly check
starting from here.
Cc: Lucas De Marchi
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i9
Quoting Chris Wilson (2018-10-19 21:11:11)
> Quoting Ville Syrjala (2018-10-19 20:59:48)
> > From: Ville Syrjälä
> >
> > Now that we can actually grab the rotation data from the VBT,
> > maybe we can get rid of the hardware readout path? My VLV
> > FFRD is still happy.
>
> Module reload? kexec?
Quoting Ville Syrjala (2018-10-19 20:59:48)
> From: Ville Syrjälä
>
> Now that we can actually grab the rotation data from the VBT,
> maybe we can get rid of the hardware readout path? My VLV
> FFRD is still happy.
Module reload? kexec? hibernation?
-Chris
___
Quoting Ville Syrjala (2018-10-19 17:55:02)
> From: Ville Syrjälä
>
> Once we've switched to using the swcursor (possibly
> due to the cursor ioctl failing) we currently keep
> using the swcursor until the modeset.
>
> That's not particularly great as the swcursor has several
> issues. Apart fro
From: Ville Syrjälä
Now that we can actually grab the rotation data from the VBT,
maybe we can get rid of the hardware readout path? My VLV
FFRD is still happy.
Cc: Hans de Goede
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/vlv_dsi.c | 42 --
1 file ch
From: Ville Syrjälä
VBT appears to have two (or possibly three) ways to indicate the panel
rotation. The first is in the MIPI config block, but that apparenly
usually (maybe always?) indicates 0 degrees despite the actual panel
orientation. The second way to indicate this is in the general featur
From: Ville Syrjälä
Let's make sure the DSI port is actually on before we go
poking at the plane register to determine which way
it's rotated. Otherwise we could be looking at a plane
that is feeding a HDMI port for instance.
And in order to read the plane register we need the power
well to be o
On Fri, Oct 19, 2018 at 12:24:43PM -0700, Manasi Navare wrote:
> On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
> > On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> > > If FEC is supported, the corresponding
> > > DP_TP_CTL register bits have to be configured.
> >
On Fri, Oct 19, 2018 at 12:03:35PM -0700, Rodrigo Vivi wrote:
> No functional change.
>
> Just sorting this "if" statement from newer to older platform.
Sure. Why not.
Reviewed-by: Ville Syrjälä
>
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_uncore.c |
On Fri, Oct 19, 2018 at 12:03:34PM -0700, Rodrigo Vivi wrote:
> No functional change.
>
> Just sorting this "if" block from newer to older platform.
>
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 17 -
> 1 file changed, 8 ins
On Fri, Oct 19, 2018 at 12:03:33PM -0700, Rodrigo Vivi wrote:
> Just sorting this "if" block from newer to older platform.
>
> The main difference here is the addition of a
> missing case with return false that should never occur.
> And if it occurs it is better than to raise a warn
> than use the
On Fri, Oct 19, 2018 at 12:03:32PM -0700, Rodrigo Vivi wrote:
> No functional change.
>
> Just sorting this "if" block from newer to older platform.
>
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
> 1 file cha
On Fri, Oct 19, 2018 at 12:03:31PM -0700, Rodrigo Vivi wrote:
> No functional change.
>
> Just sorting this "if" block from newer to older platform.
>
> Cc: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
> 1 file changed, 6 insertions(+),
On Fri, Oct 19, 2018 at 12:11:53PM -0700, Rodrigo Vivi wrote:
> We don't need 2 different blocks.
> Specially with on in ordered older-to-newer and the other
> one newer-to-older.
>
> Let's start always using newer-to-older order
> when it makes sense.
>
> Cc: Ville Syrjälä
> Signed-off-by: Rodr
On Fri, Oct 19, 2018 at 09:39:11PM +0300, Ville Syrjälä wrote:
> On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> > If FEC is supported, the corresponding
> > DP_TP_CTL register bits have to be configured.
> >
> > The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
We don't need 2 different blocks.
Specially with on in ordered older-to-newer and the other
one newer-to-older.
Let's start always using newer-to-older order
when it makes sense.
Cc: Ville Syrjälä
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_cdclk.c | 91 ++---
No functional change.
Just sorting this "if" statement from newer to older platform.
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i9
Just sorting this "if" block from newer to older platform.
The main difference here is the addition of a
missing case with return false that should never occur.
And if it occurs it is better than to raise a warn
than use the icl one.
The gen >= 11 was already present in the previous logic,
althou
No functional change.
Just sorting this "if" block from newer to older platform.
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
This general approach has been acked by Jani on an RFC patch
that I sent yesterday.
But when rebasing it on drm-tip I noticed that it would be better
for review if I split this in very small chunks.
As I wrote yesterday I consider and tried to start using coccinelle
here but in the end, at least
No functional change.
Just sorting this "if" block from newer to older platform.
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/in
No functional change.
Just sorting this "if" block from newer to older platform.
Cc: Jani Nikula
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/
On Mon, Oct 15, 2018 at 02:50:37PM -0700, Anusha Srivatsa wrote:
> Set the suitable bits in DP_TP_CTL to stop
> bit correction when DSC is disabled.
>
> v2:
> - rebased.
> - Add additional check for compression state. (Gaurav)
>
> v3: rebased.
>
> Cc: Gaurav K Singh
> Cc: Jani Nikula
> Cc: Vil
On Mon, Oct 15, 2018 at 02:50:36PM -0700, Anusha Srivatsa wrote:
> If FEC is supported, the corresponding
> DP_TP_CTL register bits have to be configured.
>
> The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
> and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
> Also add the warn me
>-Original Message-
>From: Navare, Manasi D
>Sent: Thursday, October 18, 2018 4:16 PM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Singh, Gaurav K
>;
>Jani Nikula ; Ville Syrjala
>
>Subject: Re: [v2 6/6] drm/i915/fec: Disable FEC state.
>
>Hi Anusha,
>
>Find my comments b
On Fri, Oct 19, 2018 at 09:41:37AM -0700, Rodrigo Vivi wrote:
> On Fri, Oct 19, 2018 at 01:33:08PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 19, 2018 at 10:30:46AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> > > > On Thu, 18 Oct 2018, Rodrigo V
On Fri, Oct 19, 2018 at 09:46:13AM -0700, Lucas De Marchi wrote:
> On Fri, Oct 19, 2018 at 10:39:46AM +0300, Jani Nikula wrote:
> > On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > > Now that we have the number of ddi ports information available
> > > let's use it instead of that ugly platform macro.
Let's add a platform has_sagv instead of having a full
function that handle platform by platform.
The specially case for SKL for not controlled sagv
is already taken care inside intel_enable_sagv, so there's
no need to duplicate the check here.
v2: Go one step further and remove skl special case.
On Fri, Oct 19, 2018 at 04:22:29PM +0200, Maarten Lankhorst wrote:
> Op 18-10-18 om 18:00 schreef Ville Syrjälä:
> > On Thu, Oct 18, 2018 at 01:51:29PM +0200, Maarten Lankhorst wrote:
> >> To make NV12 working on icl, we need to update 2 planes simultaneously.
> >> I've chosen to do this in the CRT
On Fri, Oct 19, 2018 at 01:33:08PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 19, 2018 at 10:30:46AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> > > On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > > > Continuing with the goal of use less platform code
From: Ville Syrjälä
Once we've switched to using the swcursor (possibly
due to the cursor ioctl failing) we currently keep
using the swcursor until the modeset.
That's not particularly great as the swcursor has several
issues. Apart from the (presumably expected) flicker,
the cursor also tends t
On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > Continuing with the goal of use less platform codenames:
> > let's group platforms who has gen10 display.
>
> Ahah, so this answers my question in the previous patch. ;)
>
> So we already
On Fri, Oct 19, 2018 at 10:39:46AM +0300, Jani Nikula wrote:
> On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > Now that we have the number of ddi ports information available
> > let's use it instead of that ugly platform macro.
> >
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i9
On Fri, Oct 19, 2018 at 01:33:08PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 19, 2018 at 10:30:46AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> > > On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > > > Continuing with the goal of use less platform code
On 19/10/2018 17:19, Daniele Ceraolo Spurio wrote:
CC some mesa people here? not sure who the right contact would be for
this
Adding Anuj.
-
Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On 19/10/18 08:19, Tomasz Lis wrote:
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now versioned; the patch includes version 1 entries.
A bit more explanation is required here. We need to make clear the fact
that existing entries in the table
On 2018-10-16 12:53, Joonas Lahtinen wrote:
Quoting Tomasz Lis (2018-10-15 20:29:18)
The patch adds support of preempt-to-idle requesting by setting a proper
bit within Execlist Control Register, and receiving preemption result from
Context Status Buffer.
Preemption in previous gens required
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now versioned; the patch includes version 1 entries.
BSpec: 34007
BSpec: 560
Signed-off-by: Tomasz Lis
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Zhenyu Wang
---
drivers/gpu/drm/i91
On Fri, Oct 19, 2018 at 03:49:15PM +0200, Hans de Goede wrote:
> Hi,
>
> On 19-10-18 11:20, Jani Nikula wrote:
> > On Wed, 17 Oct 2018, Hans de Goede wrote:
> > > On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
> > > different frequency then the pclk which we've calculated.
Op 18-10-18 om 18:00 schreef Ville Syrjälä:
> On Thu, Oct 18, 2018 at 01:51:29PM +0200, Maarten Lankhorst wrote:
>> To make NV12 working on icl, we need to update 2 planes simultaneously.
>> I've chosen to do this in the CRTC step after plane validation is done,
>> so we know what planes are (in)vi
Op 19-10-18 om 15:06 schreef Chris Wilson:
> Quoting Maarten Lankhorst (2018-10-19 14:03:47)
>> Op 18-10-18 om 17:11 schreef Ville Syrjälä:
>>> On Thu, Oct 18, 2018 at 01:51:27PM +0200, Maarten Lankhorst wrote:
@@ -4402,8 +4401,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
*cstate,
Hi,
On 19-10-18 11:20, Jani Nikula wrote:
On Wed, 17 Oct 2018, Hans de Goede wrote:
On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
different frequency then the pclk which we've calculated.
This commit makes the DSI code read-back the pclk set by the GOP and
if that is w
Quoting Maarten Lankhorst (2018-10-19 14:03:47)
> Op 18-10-18 om 17:11 schreef Ville Syrjälä:
> > On Thu, Oct 18, 2018 at 01:51:27PM +0200, Maarten Lankhorst wrote:
> >> @@ -4402,8 +4401,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> >> *cstate,
> >> * result is < available as
Op 18-10-18 om 17:11 schreef Ville Syrjälä:
> On Thu, Oct 18, 2018 at 01:51:27PM +0200, Maarten Lankhorst wrote:
>> On gen11, we can definitely smash the 32-bits barrier with just a
>> when we enable all planes in the next patch.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i9
Op 18-10-18 om 16:53 schreef Ville Syrjälä:
> On Thu, Oct 18, 2018 at 01:51:27PM +0200, Maarten Lankhorst wrote:
>> On gen11, we can definitely smash the 32-bits barrier with just a
>> when we enable all planes in the next patch.
>>
>> Signed-off-by: Maarten Lankhorst
> I guess the per-plane data
Quoting Mika Kuoppala (2018-10-19 13:30:37)
> If we try to initialize a framebuffer without pipes, we get oops
> as we fail to get valid crtc for a PIPE A, on trying to find
> pitch limits. This is easily demonstrated by trying to init
> framebuffer with displays disabled by 'i915.disable_display=1
On Fri, Oct 19, 2018 at 12:38 PM Joonas Lahtinen
wrote:
>
> Hi Dave,
>
> Here are the promised MST fixes that were missing due to being
> in i915 tree, yet outside i915 directory.
>
> Further explanation in the previous PR's thread.
fwiw, lgtm.
Cheers, Daniel
>
> Regards, Joonas
>
> ***
>
> drm-
If we try to initialize a framebuffer without pipes, we get oops
as we fail to get valid crtc for a PIPE A, on trying to find
pitch limits. This is easily demonstrated by trying to init
framebuffer with displays disabled by 'i915.disable_display=1'
kernel cmdline.
Fix this by omitting framebuffer
Quoting Xiong Zhang (2018-10-18 06:40:31)
> Currently the guest couldn't boot up under GVT-g environment as the
> following call trace exists:
> [ 272.504762] BUG: unable to handle kernel NULL pointer dereference at
> 0100
> [ 272.504834] Call Trace:
> [ 272.504852] execlists_conte
Hey Dave,
The GPF issue was serious enough to send a second pull request for
drm-misc-fixes. :)
Cheers,
~Maarten
drm-misc-fixes-2018-10-19:
Second pull request for v4.19:
- Fix ulong overflow in sun4i
- Fix a serious GPF in waiting for flip_done from commit_tail().
The following changes since
Hi Dave,
Here are the promised MST fixes that were missing due to being
in i915 tree, yet outside i915 directory.
Further explanation in the previous PR's thread.
Regards, Joonas
***
drm-intel-next-fixes-2018-10-19:
- The missing 4 MST patches that tooling didn't pick from drm core/nouveau
The
On Thu, Oct 18, 2018 at 04:34:42PM -0700, Rodrigo Vivi wrote:
> Whenever possible let's move towards preferring gen number
> and or features instead of hard coding platform codename
> everywhere.
Not a big fan of this idea. The gen numbers are simply
confusing when talking about the display.
>
>
On Fri, Oct 19, 2018 at 10:30:46AM +0200, Daniel Vetter wrote:
> On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> > On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > > Continuing with the goal of use less platform codenames:
> > > let's group platforms who has gen10 display.
> >
> > Ahah
> Quoting Zhang, Xiong Y (2018-10-19 11:11:23)
> > > Quoting Zhenyu Wang (2018-10-19 04:05:20)
> > > > On 2018.10.18 13:40:31 +0800, Xiong Zhang wrote:
> > > > > Currently the guest couldn't boot up under GVT-g environment as
> > > > > the following call trace exists:
> > > > > [ 272.504762] BUG:
On Fri, 19 Oct 2018 01:10:10 +0200, Daniele Ceraolo Spurio
wrote:
A collection of very small cleanups/improvements around doorbell checking
that do not deserve their own patch:
- Move doorbell-related HW defs to intel_guc_reg.h
- use GUC_NUM_DOORBELLS instead of GUC_DOORBELL_INVALID where
We wrongly assumed that GuC is only using last scratch register
for G2H messages, but in fact it is also using register [14] to
report sleep state status. Remove that register from our H2G
send registers pool.
v2: No message from host to GuC uses more than 8 registers and
the GuC FW itself uses an
GuC is disabled by default. Enable it.
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 7e56c51..c681537 100644
--- a/drivers/g
Quoting Zhang, Xiong Y (2018-10-19 11:11:23)
> > Quoting Zhenyu Wang (2018-10-19 04:05:20)
> > > On 2018.10.18 13:40:31 +0800, Xiong Zhang wrote:
> > > > Currently the guest couldn't boot up under GVT-g environment as the
> > > > following call trace exists:
> > > > [ 272.504762] BUG: unable to ha
> Quoting Zhenyu Wang (2018-10-19 04:05:20)
> > On 2018.10.18 13:40:31 +0800, Xiong Zhang wrote:
> > > Currently the guest couldn't boot up under GVT-g environment as the
> > > following call trace exists:
> > > [ 272.504762] BUG: unable to handle kernel NULL pointer dereference
> > > at 0
Quoting Daniel Vetter (2018-10-19 10:05:32)
> On Fri, Oct 19, 2018 at 8:59 AM Joonas Lahtinen
> wrote:
> >
> > Quoting Daniel Vetter (2018-10-18 22:32:00)
> > > On Thu, Oct 18, 2018 at 6:57 PM Joonas Lahtinen
> > > wrote:
> > > >
> > > > Hi Dave,
> > > >
> > > > Here comes the final set of fixes
Quoting Daniel Vetter (2018-10-19 11:30:46)
> On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> > On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > > Continuing with the goal of use less platform codenames:
> > > let's group platforms who has gen10 display.
> >
> > Ahah, so this answers m
On Wed, 17 Oct 2018, Hans de Goede wrote:
> On BYT and CHT the GOP sometimes initializes the pclk at a (slightly)
> different frequency then the pclk which we've calculated.
>
> This commit makes the DSI code read-back the pclk set by the GOP and
> if that is within a reasonable margin of the calc
Hi all,
This is just to collect feedback on this idea, and see whether the
overall dri-devel community stands on all this. I think the past few
cross-vendor uapi extensions all came with igts attached, and
personally I think there's lots of value in having them: A
cross-vendor interface isn't usef
Quoting Daniel Vetter (2018-10-19 09:22:15)
> On Mon, Oct 15, 2018 at 12:17:41PM +0100, Chris Wilson wrote:
> > If the user passes i915.disable_display=1 we want to disable all the
> > displays and associated HW like the powerwells on their behalf. Instead
> > of short circuiting the HW probe, let
Quoting Daniel Vetter (2018-10-19 09:23:54)
> On Mon, Oct 15, 2018 at 12:17:39PM +0100, Chris Wilson wrote:
> > We try to avoid a deadlock of synchronizing the async fbdev task by
> > skipping the synchronisation from the async worker, but that prevents us
> > from using an async worker for the dev
On Fri, Oct 19, 2018 at 11:03:53AM +0300, Jani Nikula wrote:
> On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > Continuing with the goal of use less platform codenames:
> > let's group platforms who has gen10 display.
>
> Ahah, so this answers my question in the previous patch. ;)
>
> So we already
On Fri, Oct 19, 2018 at 10:39:46AM +0300, Jani Nikula wrote:
> On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> > Now that we have the number of ddi ports information available
> > let's use it instead of that ugly platform macro.
> >
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i9
On Mon, Oct 15, 2018 at 12:17:39PM +0100, Chris Wilson wrote:
> We try to avoid a deadlock of synchronizing the async fbdev task by
> skipping the synchronisation from the async worker, but that prevents us
> from using an async worker for the device probe. As we have our own
> barrier and do not r
On Mon, Oct 15, 2018 at 12:17:41PM +0100, Chris Wilson wrote:
> If the user passes i915.disable_display=1 we want to disable all the
> displays and associated HW like the powerwells on their behalf. Instead
> of short circuiting the HW probe, let it run and setup all the
> bookkeeping for the known
On Thu, Oct 18, 2018 at 03:48:04PM -0700, Jeff McGee wrote:
> On Thu, Oct 18, 2018 at 11:12:21AM -0700, Rodrigo Vivi wrote:
> > On Thu, Oct 18, 2018 at 10:32:37AM -0700, Jeff McGee wrote:
> > > On Thu, Oct 18, 2018 at 11:57:06AM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 12, 2018 at 11:45 PM J
On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> Let's just handle SKL as special case instead of listing
> platform by platform.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_pm.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i
On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> Let's use this whenever it makes sense and code gets
> easier to read.
Ack on this general direction.
BR,
Jani.
>
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_ddi.c| 18 +-
> drivers/gpu/drm/i915/intel_dp.
On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> Also let's always consider next platform follows
> the most recent one. Like we have done for transitioning
> gen9 to gen10 and gent10 to gen11.
>
> Let's use same approach for gen11+ and only introduce
> changes later as needed.
Same worry as with Gemin
On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> Continuing with the goal of use less platform codenames:
> let's group platforms who has gen10 display.
Ahah, so this answers my question in the previous patch. ;)
So we already have HAS_GMCH_DISPLAY().
If we're going to make gen10 display a thing, sho
On Thu, 18 Oct 2018, Rodrigo Vivi wrote:
> Whenever possible let's move towards preferring gen number
> and or features instead of hard coding platform codename
> everywhere.
Rationale missing.
But for gem, agreed, it largely makes sense. For display, I'm not sure
if this is a good idea. Conside
1 - 100 of 111 matches
Mail list logo
