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,
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
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 +-
>
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
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
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
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
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
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
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
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
> > ---
> >
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
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
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 under -next-fixes umbrella.
> > > Next one will be then from
To improve GVTg performance, it could reduce the mmio access trap
numbers within guest driver in some certain scenarios since mmio
access trap will introuduce vm exit/vm enter cost.
the solution in this patch set is to setup a shared memory region
which accessed both by guest and GVTg without
Master irq register is accessed twice every irq handling, then trapped
to SOS very frequently. Optimize it by moving master irq register
to share page, writing don't need be trapped.
When need enable irq to let SOS inject irq timely, use another pvmmio
register to achieve this purpose. So avoid
To enable pvmmio feature, we need to prepare one 4K shared page
which will be accessed by both guest and backend i915 driver.
guest i915 allocate one page memory and then the guest physical address is
passed to backend i915 driver through PVINFO register so that backend i915
driver can access
This u32 pv_caps field is used to control the different
level pvmmio feature for MMIO emulation in GVT.
This field is default zero, no pvmmio feature enabled.
it also add VGT_CAPS_PVMMIO capability BIT for guest to check GVTg
can support PV feature or not.
v0: RFC, introudced enable_pvmmio
This patch extends g2v notification to notify host GVT-g of
ppgtt update from guest, including alloc_4lvl, clear_4lv4 and
insert_4lvl. It uses shared page to pass the additional params.
This patch also add one new pvmmio level to control ppgtt update.
Use PVMMIO_PPGTT_UPDATE to control this level
It is performance optimization to reduce mmio trap numbers from 4 to
1 durning ELSP porting writing (context submission).
When context subission, to cache elsp_data[4] values in
the shared page, the last elsp_data[0] port writing will be trapped
to gvt for real context submission.
Use
Hi all,
We are pleased to announce an update of Intel GVT-g for KVM.
Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with
mediated pass-through, starting from 5th generation Intel Core(TM) processors
with Intel processor graphics. A virtual GPU instance is
Hi all,
We are pleased to announce an update of Intel GVT-g for Xen.
Intel GVT-g is a full GPU virtualization solution with mediated pass-through,
starting from 4th generation Intel Core(TM) processors with Intel processor
graphics. A virtual GPU instance is maintained for each VM, with
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/i915_drv.c | 10 ++
> drivers/gpu/drm/i915/i915_drv.h
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 under -next-fixes umbrella.
> > Next one will be then from -fixes, assuming a release next Sun.
> >
> > Fixes for bunch of display
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
> > 0100
>
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.
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
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
>> ---
>>
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
---
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,
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
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
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
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
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
> > ---
> >
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
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
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
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
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
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.
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:
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
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
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
>-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
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
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 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]
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
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:
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
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]
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
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
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:
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?
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
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 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
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(+),
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
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
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
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
---
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 +-
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
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
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
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
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
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
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
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,
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
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,
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
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
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 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:
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
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
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 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
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
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
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 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
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
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
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
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
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.
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
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
>
> ***
>
>
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
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]
1 - 100 of 110 matches
Mail list logo
