Hi José,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v5.0-rc4 next-20190207]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
> -Original Message-
> From: Winkler, Tomas
> Sent: Friday, February 8, 2019 3:42 AM
> To: C, Ramalingam ; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
>
> Subject: RE: [PATCH v11 39/42] misc/mei/hdcp: Component framework for I91
> -Original Message-
> From: Winkler, Tomas
> Sent: Friday, February 8, 2019 3:05 AM
> To: C, Ramalingam ; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Shankar, Uma
>
> Subject: RE: [PATCH v11 28/42] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx
>
== Series Details ==
Series: series starting with [1/4] component: Add documentation
URL : https://patchwork.freedesktop.org/series/56372/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5564_full -> Patchwork_12174_full
Summ
== Series Details ==
Series: series starting with [1/6] drm/i915: Compute has_drrs after compute
has_psr
URL : https://patchwork.freedesktop.org/series/56369/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5564_full -> Patchwork_12173_full
=
u/drm/arm/display/komeda/komeda_dev.c:170:3: error: implicit
declaration of function 'devm_iounmap'; did you mean 'pci_iounmap'?
[-Werror=implicit-function-declaration]
devm_iounmap(dev, mdev->reg_base);
^~~~
pci_iounmap
and lots more ...
Probably caused
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function 'sun6i_dsi_probe':
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1053:9: warning: 'ret' may be used
uninitialized in this function [-Wmay
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_display.c
between commit:
9f58892ea996 ("drm/i915: Pull all the reset functionality together into
i915_reset.c")
from the drm tree and commit:
d0e93599d396 ("drm/i915: prepare for drmP.h
== Series Details ==
Series: Enable/disable gamma/csc dynamically and fix C8 (rev2)
URL : https://patchwork.freedesktop.org/series/56365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5563_full -> Patchwork_12172_full
Summa
== Series Details ==
Series: series starting with [1/4] component: Add documentation
URL : https://patchwork.freedesktop.org/series/56372/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5564 -> Patchwork_12174
Summary
--
== Series Details ==
Series: series starting with [1/4] component: Add documentation
URL : https://patchwork.freedesktop.org/series/56372/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4b25d63c44e7 component: Add documentation
-:27: WARNING:TYPO_SPELLING: 'superflous' may be mi
On Fri, Feb 8, 2019 at 12:28 AM Daniel Vetter wrote:
>
> Component framework is extended to support multiple components for
> a struct device. These will be matched with different masters based on
> its sub component value.
>
> We are introducing this, as I915 needs two different components
> with
Since we need multiple components for I915 for different purposes
(Audio & Mei_hdcp), we adopt the subcomponents methodology introduced
by the previous patch (mentioned below).
Author: Daniel Vetter
Date: Mon Jan 28 17:08:20 2019 +0530
components: multiple component
Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.
We are introducing this, as I915 needs two different components
with different subcomponent value, which will be matched to two
differe
While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
component/puppetmaster or something like that. At least to my
English ear "aggregate" emphasizes much more the "assemble a pile
Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.
Cc: Russell King - ARM Linux admin
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 2 ++
Documentation/gpu/drm-internals.rst| 5 +
drivers/gpu/drm
== Series Details ==
Series: series starting with [1/6] drm/i915: Compute has_drrs after compute
has_psr
URL : https://patchwork.freedesktop.org/series/56369/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5564 -> Patchwork_12173
===
On Thu, Feb 7, 2019 at 9:33 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Rather than try to maintain some magic relationship between the link
> rates and the index into the wrpll params array let's just store
> the link rate in the array itself. Much less fragile.
>
> Signed-off-by: Ville
On Thu, Feb 7, 2019 at 11:40 PM Daniel Vetter wrote:
>
> On Wed, Feb 06, 2019 at 11:57:04PM +0100, Rafael J. Wysocki wrote:
> > ) On Wed, Feb 6, 2019 at 5:46 PM Daniel Vetter
> > wrote:
> > >
> > > Component framework is extended to support multiple components for
> > > a struct device. These wi
On Thu, Feb 7, 2019 at 9:33 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The readout code thinks that kdiv of 3 is 4. Fix it.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
> 2 files changed, 3 insertions(+),
On Wed, Feb 06, 2019 at 11:57:04PM +0100, Rafael J. Wysocki wrote:
> ) On Wed, Feb 6, 2019 at 5:46 PM Daniel Vetter wrote:
> >
> > Component framework is extended to support multiple components for
> > a struct device. These will be matched with different masters based on
> > its sub component val
On Wed, Feb 06, 2019 at 11:57:04PM +0100, Rafael J. Wysocki wrote:
> ) On Wed, Feb 6, 2019 at 5:46 PM Daniel Vetter wrote:
> >
> > Component framework is extended to support multiple components for
> > a struct device. These will be matched with different masters based on
> > its sub component val
This interlaced restriction applies to all gens, not only to Haswell.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/driv
Changes in the configuration could cause PSR to be compatible and
enabled so driver must also be able to disable DRRS when doing
fastsets.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109263
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108341
Bugzilla: https://bugs.freedesktop.
Now we are checking sink capabilities when probing PSR DPCD register
and then dynamically checking in if new state is compatible with PSR
in, so this FIXME can be dropped.
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 5 -
1 file changed
Even when driver is reload and hits this scenario the PSR mutex
should be initialized, otherwise reading PSR debugfs status will
execute mutex_lock() over a mutex that was not initialized.
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 1 -
1
Changes done:
- Renamed refresh_rate_type to current_refresh_rate, for better
reading
- Replaced 'int refresh_rate' parameter to
'enum drrs_refresh_rate_type rate_type', refresh_rate is only used to
print debug information
- Removed all the parameter error checks, all of that is already
checked or
DRRS and PSR can't be enable together, so giving preference to PSR
as it allows more power-savings by complete shutting down display,
so to guarantee this intel_dp_drrs_compute_config() must be called
after intel_psr_compute_config().
Cc: Dhinakaran Pandiyan
Cc: Maarten Lankhorst
Signed-off-by:
== Series Details ==
Series: Enable/disable gamma/csc dynamically and fix C8 (rev2)
URL : https://patchwork.freedesktop.org/series/56365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5563 -> Patchwork_12172
Summary
---
> Mei hdcp driver is designed as component slave for the I915 component
> master.
>
> v2: Rebased.
> v3:
> Notifier chain is adopted for cldev state update [Tomas]
> v4:
> Made static dummy functions as inline in mei_hdcp.h
> API for polling client device status
> IS_ENABLED used in header
On Wed, 2019-02-06 at 18:56 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2019-02-06 at 13:18 -0800, José Roberto de Souza wrote:
> > Changing the i915_edp_psr_debug was enabling, disabling or
> > switching
> > PSR version by directly calling intel_psr_disable_locked() and
> > intel_psr_enable_locked
On Thu, Feb 07, 2019 at 04:07:33PM -0500, Sean Paul wrote:
> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> > The only thing now that makes drm_dev_unplug() special is that it sets
> > drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> > can remove drm_dev
>
> Request the ME to terminate the HDCP2.2 session for a port.
>
> On Success, ME FW will mark the intel port as Deauthenticated and terminate
> the wired HDCP2.2 Tx session started due to the cmd
> WIRED_INITIATE_HDCP2_SESSION.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [To
>
> Request to ME to verify the M_Prime received from the HDCP sink.
>
> ME FW will calculate the M and compare with M_prime received as part of
> RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
>
> On successful completion of this stage, downstream propagation of the stream
> manageme
>
> Request to ME to configure a port as authenticated.
>
> On Success, ME FW will mark the port as authenticated and provides HDCP
> cipher with the encryption keys.
>
> Enabling the Authentication can be requested once all stages of
> HDCP2.2 authentication is completed by interacting with ME
>
> Request to ME to prepare the encrypted session key.
>
> On Success, ME provides Encrypted session key. Function populates the
> HDCP2.2 authentication msg SKE_Send_Eks.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
> Request ME to verify the downstream topology information received.
>
> ME FW will validate the Repeaters receiver id list and downstream topology.
>
> On Success ME FW will provide the Least Significant 128bits of VPrime, which
> forms the repeater ack.
>
> v2: Rebased.
> v3:
> cldev is pass
> Request to ME to verify the LPrime received from HDCP sink.
>
> On Success, ME FW will verify the received Lprime by calculating and
> comparing with L.
>
> This represents the completion of Locality Check.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant com
> Provides Pairing info to ME to store.
>
> Pairing is a process to fast track the subsequent authentication with the same
> HDCP sink.
>
> On Success, received HDCP pairing info is stored in non-volatile memory of ME.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Red
>
> Requests ME to start the second stage of HDCP2.2 authentication, called
> Locality Check.
>
> On Success, ME FW will provide LC_Init message to send to hdcp sink.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
> v4:
>
>
> Requests for the verification of AKE_Send_H_prime.
>
> ME will calculate the H and comparing it with received H_Prime.
> The result will be returned as status.
>
> Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
>
On Sat, Jan 26, 2019 at 01:25:22PM +0100, Sam Ravnborg wrote:
> Updated patchset, with merged patches removed, new patches added.
>
> > From the original mail:
>
> - drmP.h is now stripped down to include files
> and forward declarations.
> - All header files in include/
> Request ME FW to start the HDCP2.2 session for an intel port.
> Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
> to ME FW.
>
> On Success, ME FW will start a HDCP2.2 session for the port and provides the
> content for HDCP2.2 AKE_Init message.
>
> v2: Rebased.
> v3:
> cl
On Wed, Feb 06, 2019 at 09:13:32AM +0200, Jani Nikula wrote:
> On Tue, 05 Feb 2019, Ville Syrjälä wrote:
> > On Tue, Feb 05, 2019 at 03:42:05PM +0200, Jani Nikula wrote:
> >>
> >> The following commits have been marked as Cc: stable or fixing something
> >> in v5.0-rc5 or earlier, but failed to c
> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, February 06, 2019 23:04
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma
> Cc: C, Ramalingam
> Subject: [PATCH v11 29/42] misc/mei/hdcp: Verify
On Thu, Feb 07, 2019 at 08:56:35PM -, Patchwork wrote:
> == Series Details ==
>
> Series: Enable/disable gamma/csc dynamically and fix C8
> URL : https://patchwork.freedesktop.org/series/56365/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5562 -> Patchwork_12171
On Sun, Feb 03, 2019 at 04:42:00PM +0100, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
> diff --git
On Sun, Feb 03, 2019 at 04:41:58PM +0100, Noralf Trønnes wrote:
> drm_dev_unplug() has been stripped down and is going away. Open code its
> 2 remaining function calls.
>
> Cc: Dave Airlie
> Cc: Sean Paul
Reviewed-by: Sean Paul
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/udl/udl
> ME FW contributes a vital role in HDCP2.2 authentication.
> HDCP2.2 driver needs to communicate to ME FW for each step of the
> HDCP2.2 authentication.
>
> ME FW prepare and HDCP2.2 authentication parameters and encrypt them as
> per spec. With such parameter Driver prepares HDCP2.2 auth messag
On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Maybe s/u
Make sure that the SIGARLM handler is captured so that we don't
accidentally shoot ourselves in the foot instead of merely waking up the
execbuf.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git
On Sun, Feb 03, 2019 at 04:41:55PM +0100, Noralf Trønnes wrote:
> If userspace has open fd(s) when drm_dev_unplug() is run, it will result
> in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
> then later in drm_release() through the call to drm_put_dev().
>
> Since userspac
== Series Details ==
Series: Enable/disable gamma/csc dynamically and fix C8
URL : https://patchwork.freedesktop.org/series/56365/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5562 -> Patchwork_12171
Summary
---
**F
== Series Details ==
Series: series starting with [01/13] drm/i915: Don't pass crtc to
intel_find_shared_dpll()
URL : https://patchwork.freedesktop.org/series/56354/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5561_full -> Patchwork_12169_full
==
From: Ville Syrjälä
Track whether pipe gamma is enabled or disabled. For now we
stick to the current behaviour of always enabling gamma. But
we do get working state readout for this now. On SKL+ we use
the pipe bottom color as our hardware state. On pre-SKL we
read the state back from the primary
From: Ville Syrjälä
On pre-HSW gamma mode is configured via PIPECONF. The bits are
the same except shifted up, so we can reuse just store them in
crtc_state->gamma_mode in the HSW+ way, allowing us to share
some code later.
v2: Allow fastboot with gamma_mode changes (Maarten)
Add space aroun
From: Ville Syrjälä
On g4x+ we depend on the primary plane DSPCNTR gamma/csc enable
bits for the pipe bottom color. To guarantee that those are
correct already when enabling the crtc let's do an explicit
->disable_plane() call before enabling the pipe.
On skl+ this will be handled by the explici
From: Ville Syrjälä
Just like we did for pipe gamma, let's also track the pipe csc
state. The hardware only exists on ILK+, and currently we always
enable it on hsw+ and never on any other platforms. Just like
with pipe gamma, the primary plane control register is used
for the readout on pre-SKL,
From: Ville Syrjälä
Planes scanning out C8 will want to use the legacy lut as
their palette. That means the LUT content are unlikely to
be useful for gamma correction on other planes. Thus we
should disable pipe gamma for all the other planes. And
we should reject any non legacy LUT configuration
From: Ville Syrjälä
As with pipe gamma we can avoid the potential precision loss from
the pipe csc unit when there is no need to use it. And again
we need the same logic for updating the planes.
v2: Rebase
Signed-off-by: Ville Syrjälä
Reviewed-by: Uma Shankar
Reviewed-by: Matt Roper
---
dri
From: Ville Syrjälä
The pipe internal precision is higher than what we currently program to
the degamma/gamma LUTs. We can get a higher quality image by bypassing
the LUTs when they're not needed. Let's do that.
Each plane has its own control bit for this, so we have to update
all active planes.
From: Ville Syrjälä
Track whether pipe gamma is enabled or disabled. For now we
stick to the current behaviour of always enabling gamma. But
we do get working state readout for this now. On SKL+ we use
the pipe bottom color as our hardware state. On pre-SKL we
read the state back from the primary
From: Ville Syrjälä
Here's the remainder of my gamma stuff. All reviwed so should
be good to land as soon as CI gives the green light.
Only real change from the last posting is dealing with
fastboot (I hope even correctly).
Ville Syrjälä (7):
drm/i915: Populate gamma_mode for all platforms
== Series Details ==
Series: series starting with [1/3] drm/i915: Make 48bit full ppgtt
configuration generic (v11)
URL : https://patchwork.freedesktop.org/series/56350/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5561_full -> Patchwork_12168_full
==
On Thu, Feb 07, 2019 at 08:40:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 07, 2019 at 02:33:57AM +0530, Ramalingam C wrote:
> > Defining the mei-i915 interface functions and initialization of
> > the interface.
> >
> > v2:
> > Adjust to the new interface changes. [Tomas]
> > Added further d
On Thu, Feb 07, 2019 at 02:33:57AM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is equipped
== Series Details ==
Series: drm/i915: Skip scanning for signalers if we are already inflight
URL : https://patchwork.freedesktop.org/series/56357/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5561 -> Patchwork_12170
Summa
On Thu, Feb 07, 2019 at 04:46:54PM +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 05-02-2019 om 17:08 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > The LUTs are single buffered so we should program them after
> > the double buffered pipe updates have been latched by the
> > hardware.
> >
On Thu, 7 Feb 2019 16:41:58 +
Chris Wilson wrote:
> Quoting Bob Paauwe (2019-02-07 16:29:53)
> > With the address range being specified for each platform, we can use
> > that instead of the .ppgtt enum to handle the differences between
> > 3 level and 4 level PPGTT. In most cases, we really o
On Tue, Feb 05, 2019 at 07:22:32PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, February 5, 2019 11:43 PM
> >To: Shankar, Uma
> >Cc: intel-gfx@lists.freedesktop.org
When a request has its priority changed, we traverse the graph of all of
its signalers to raise their priorities to match (priority inheritance).
If the request has already started executing its payload, we know that
all of its signalers must have signaled and we do not need to process
our list of
== Series Details ==
Series: series starting with [01/13] drm/i915: Don't pass crtc to
intel_find_shared_dpll()
URL : https://patchwork.freedesktop.org/series/56354/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5561 -> Patchwork_12169
== Series Details ==
Series: series starting with [01/13] drm/i915: Don't pass crtc to
intel_find_shared_dpll()
URL : https://patchwork.freedesktop.org/series/56354/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4a516bd3c8c7 drm/i915: Don't pass crtc to intel_find_shared_dpll(
== Series Details ==
Series: series starting with [1/3] drm/i915: Make 48bit full ppgtt
configuration generic (v11)
URL : https://patchwork.freedesktop.org/series/56350/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5561 -> Patchwork_12168
== Series Details ==
Series: series starting with [1/3] drm/i915: Make 48bit full ppgtt
configuration generic (v11)
URL : https://patchwork.freedesktop.org/series/56350/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make 48bit full ppgtt co
From: Ville Syrjälä
Rather than try to maintain some magic relationship between the link
rates and the index into the wrpll params array let's just store
the link rate in the array itself. Much less fragile.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 136 +
From: Ville Syrjälä
Simplify the calling convention of the dpll funcs by plumbing
the crtc state deeper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 29 +++
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Ville Syrjälä
Just store the stuff directly into crtc_state->dpll_hw_state rather
than to a temp and copying the whole thing over.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
d
From: Ville Syrjälä
The readout code thinks that kdiv of 3 is 4. Fix it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers
From: Ville Syrjälä
Simplify the calling convention of the dpll funcs by plumbing
the crtc state deeper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
From: Ville Syrjälä
We already have the code to calculate the WRPLL output clock from
the register values, but for some reason we're only using it for
HDMI and not DP. Throw out the inflexible DP DPLL table lookup and
just call the HDMI code which decodes the actual register values.
Signed-off-b
From: Ville Syrjälä
Just store the stuff directly into crtc_state->dpll_hw_state rather
than to a temp and copying the whole thing over.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/dr
From: Ville Syrjälä
Simplify the calling convention of the dpll funcs by plumbing
the crtc state deeper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 5 +--
drivers/gpu/drm/i915/intel_dpll_mgr.c | 48 ++-
drivers/gpu/drm/i915/intel_drv.h
From: Ville Syrjälä
Simplify the calling convention of the skl dpll funcs by plumbing
the crtc state deeper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_
From: Ville Syrjälä
Just store the stuff directly into crtc_state->dpll_hw_state rather
than to a temp and copying the whole thing over.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/dr
From: Ville Syrjälä
Just store the stuff directly into crtc_state->dpll_hw_state rather
than to a temp and copying the whole thing over.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
di
From: Ville Syrjälä
Passing both crtc and its state is redundant. Pass just the state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_dpll_mgr.c | 56 +--
drivers/gpu/drm/i915/intel_dpll_mgr.h | 3 +-
3 files
From: Ville Syrjälä
Passing both crtc and its state is redundant. Pass just the state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/
On Thu, Feb 07, 2019 at 06:27:19PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 07, 2019 at 04:49:47PM +0100, Maarten Lankhorst wrote:
> > Op 05-02-2019 om 17:08 schreef Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > On pre-HSW gamma mode is configured via PIPECONF. The bits are
> > > the same
Quoting Bob Paauwe (2019-02-07 16:29:51)
> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> index 720e2b10adaa..314e40121e47 100644
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@ -44,7 +44,7 @@ void populate_pvinfo_page(struct in
Quoting Bob Paauwe (2019-02-07 16:29:53)
> With the address range being specified for each platform, we can use
> that instead of the .ppgtt enum to handle the differences between
> 3 level and 4 level PPGTT. In most cases, we really only care if the
> platform supports PPGTT or not. Because of thi
We no longer need to differentiate between 4LVL and FULL ppgtt as
the number of bits in the address range provides that information now.
Signed-off-by: Bob Paauwe
CC: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/i915_pci.c | 4 ++--
drive
With the address range being specified for each platform, we can use
that instead of the .ppgtt enum to handle the differences between
3 level and 4 level PPGTT. In most cases, we really only care if the
platform supports PPGTT or not. Because of this, we can now remove
the HAS_FULL_PPGTT macro and
48 bit ppgtt device configuration is really just extended address
range full ppgtt and may actually be something other than 48 bits.
Change HAS_FULL_48BIT_PPGTT() to HAS_4LVL_PPGTT() to better
describe that a 4 level walk table extended range PPGTT is being
used. Add a new device info field that s
On Thu, Feb 07, 2019 at 04:58:22PM +0100, Maarten Lankhorst wrote:
> Op 05-02-2019 om 17:08 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > On g4x+ we depend on the primary plane DSPCNTR gamma/csc enable
> > bits for the pipe bottom color. To guarantee that those are
> > correct already whe
On Thu, Feb 07, 2019 at 04:49:47PM +0100, Maarten Lankhorst wrote:
> Op 05-02-2019 om 17:08 schreef Ville Syrjala:
> > From: Ville Syrjälä
> >
> > On pre-HSW gamma mode is configured via PIPECONF. The bits are
> > the same except shifted up, so we can reuse just store them in
> > crtc_state->gamma
Quoting Joonas Lahtinen (2019-02-07 16:01:31)
> Quoting Chris Wilson (2019-02-07 09:18:22)
> > Apply backpressure to hogs that emit requests faster than the GPU can
> > process them by waiting for their ring to be less than half-full before
> > proceeding with taking the struct_mutex.
> >
> > This
On 2/7/2019 8:43 PM, Winkler, Tomas wrote:
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma]
v5:
Re
Quoting Joonas Lahtinen (2019-02-07 16:01:31)
> Quoting Chris Wilson (2019-02-07 09:18:22)
> > Apply backpressure to hogs that emit requests faster than the GPU can
> > process them by waiting for their ring to be less than half-full before
> > proceeding with taking the struct_mutex.
> >
> > This
Quoting Chris Wilson (2019-02-07 09:18:22)
> Apply backpressure to hogs that emit requests faster than the GPU can
> process them by waiting for their ring to be less than half-full before
> proceeding with taking the struct_mutex.
>
> This is a gross hack to apply throttling backpressure, the lon
1 - 100 of 125 matches
Mail list logo
