On 2020-06-23 at 11:58:58 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Add an out label and un-indent hdcp disable in preparation for
> hdcp_mutex. No functional changes
>
> Signed-off-by: Sean Paul
Reviewed-by: Ramalingam C
> Link:
>
== Series Details ==
Series: drm/i915: Soften the tasklet flush frequency before waits
URL : https://patchwork.freedesktop.org/series/79269/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8717_full -> Patchwork_18118_full
== Series Details ==
Series: drm/i915/tgl: Implement WAs 18011464164 and 22010931296
URL : https://patchwork.freedesktop.org/series/79268/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8717_full -> Patchwork_18117_full
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API (rev2)
URL : https://patchwork.freedesktop.org/series/78657/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8717_full -> Patchwork_18116_full
== Series Details ==
Series: series starting with [v4,1/5] drm/i915/display: Replace
drm_i915_private in voltage swing functions by intel_encoder
URL : https://patchwork.freedesktop.org/series/79265/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8717_full ->
== Series Details ==
Series: drm/probe_helper, i915: Validate MST modes against PBN limits (rev2)
URL : https://patchwork.freedesktop.org/series/77670/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8717 -> Patchwork_18119
On Wed, 2020-07-08 at 16:12 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Pimp the comments for the FBC related workarounds.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 55 ++---
> 1 file
On Wed, 2020-07-08 at 16:12 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Supposedly only skl/bxt need WaFbcHighMemBwCorruptionAvoidance.
> Do not apply to the other gen9 platforms.
Matches spec if not considering pre-production HW.
Reviewed-by: José Roberto de Souza
>
>
On Wed, 2020-07-08 at 16:12 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> GLK supposedly does not need WaFbcTurnOffFbcWatermark,
> so let's not apply it.
WA 0562 from BSpec 21664 says it applies to all GEN9 but it is probably
referring to all display GEN9.
Reviewed-by: José Roberto de
== Series Details ==
Series: drm/probe_helper, i915: Validate MST modes against PBN limits (rev2)
URL : https://patchwork.freedesktop.org/series/77670/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/probe_helper, i915: Validate MST modes against PBN limits (rev2)
URL : https://patchwork.freedesktop.org/series/77670/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
004eb5c36ca7 drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx
On Wed, 2020-07-08 at 16:12 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some platforms apply the FBC w/as in .init_clock_gating(), some
> in fbc_activate(). Move them all to .init_clock_gating() for
> consistentce. Also safer since we don't have to worry about the
> RMWs clashing with
== Series Details ==
Series: drm/i915: Soften the tasklet flush frequency before waits
URL : https://patchwork.freedesktop.org/series/79269/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8717 -> Patchwork_18118
Summary
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gem: Unpin idle contexts from
kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79260/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8715_full -> Patchwork_18114_full
This is just an atomic version of mode_valid, which is intended to be
used for situations where a driver might need to check the atomic state
of objects other than the connector itself. One such example is with
MST, where the maximum possible bandwidth on a connector can change
dynamically
From: Lee Shawn C
So far, max dot clock rate for MST mode rely on physcial
bandwidth limitation. It would caused compatibility issue
if source display resolution exceed MST hub output ability.
For example, source DUT had DP 1.2 output capability.
And MST docking just support HDMI 1.4 spec. When
Something we've been missing for a while with drivers that support MST
is being able to prune modes that can't be set due to bandwidth
limitations. So, let's go ahead and add that. This also adds a new hook
that was needed, mode_valid_ctx, so that we can grab additional locks as
needed when
== Series Details ==
Series: drm/i915/tgl: Implement WAs 18011464164 and 22010931296
URL : https://patchwork.freedesktop.org/series/79268/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8717 -> Patchwork_18117
Summary
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API (rev2)
URL : https://patchwork.freedesktop.org/series/78657/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8717 -> Patchwork_18116
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API (rev2)
URL : https://patchwork.freedesktop.org/series/78657/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3810d73918ca ACPI / LPSS: Resume Cherry Trail PWM
== Series Details ==
Series: series starting with [v4,1/5] drm/i915/display: Replace
drm_i915_private in voltage swing functions by intel_encoder
URL : https://patchwork.freedesktop.org/series/79265/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8717 -> Patchwork_18115
We include a tasklet flush before waiting on a request as a precaution
against the HW being lax in event signaling. We now have a precautionary
flush in the engine's heartbeat and so do not need to be quite so
zealous on every request wait. If we focus on the request, the only
tasklet flush that
== Series Details ==
Series: series starting with [v4,1/5] drm/i915/display: Replace
drm_i915_private in voltage swing functions by intel_encoder
URL : https://patchwork.freedesktop.org/series/79265/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast
Hi Hans,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
As today those 2 WAs have different implementation between TGL and DG1
WA pages but checking the HSD it is clear that DG1 implementation
should be used for both, also to do so is easier as we just need to
extend WA 1407928979 to B* stepping.
Both WAs are need to fix some possible render
On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede wrote:
>
> Fix the following kerneldoc warning:
>
> drivers/gpu/drm/drm_connector.c:2189:
> warning: missing initial short description on line
>
> Signed-off-by: Hans de Goede
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_connector.c | 4
On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede wrote:
>
> Hi All,
>
> Here is the privacy-screen related code which we discussed a while ago.
> This series consists of a number of different parts:
>
> 1. A new version of Rajat's privacy-screen connector properties patch,
> this adds new userspace
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v4:
- Use DIV_ROUND_UP when calculating the period and duty_cycle from the
controller's register values
Changes in v3:
- Add
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
controls a separate output-only GPIO which is connected to the LCD panels
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Signed-off-by: Hans de Goede
---
Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
drivers/pwm/pwm-crc.c | 89 ++-
1 file
The datasheet specifies that programming the base_unit part of the
ctrl register to 0 results in a contineous low signal.
Adjust the get_state method to reflect this by setting pwm_state.period
to 1 and duty_cycle to 0.
Suggested-by: Uwe Kleine-König
Signed-off-by: Hans de Goede
---
Changes in
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 =
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input
Hi All,
Here is v4 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
Initially the plan was for this series to consist of 2 parts:
1. convert the pwm-crc driver to
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /*
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Enabling by default to have some testing in CI but the desired behavior
is only enable it when HW/VBT says it is supported.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
intel_encoder will be needed inside of vswing functions in a future
patch, so here doing this change in all vswing functions since HSW.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 164 +--
1 file changed, 95 insertions(+), 69
Hours Of Battery Life is a new GEN12+ power-saving feature that allows
supported motherboards to use a special voltage swing table for eDP
panels that uses less power.
So here if supported by HW, OEM will set it in VBT and i915 will try
to train link with HOBL vswing table if link training fails
This information can be get directly from intel_encoder so no need
of those parameters.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 33 ++--
1 file changed, 14 insertions(+), 19 deletions(-)
diff --git
HOBL means hours of battery life, it is a power-saving feature
were supported motherboards can use a special voltage swing table
that uses less power.
So here parsing the VBT to check if this feature is supported.
BSpec: 20150
Reviewed-by: Anusha Srivatsa
Signed-off-by: José Roberto de Souza
Quoting Daniele Ceraolo Spurio (2020-07-08 01:39:52)
> In line with what happened for other gt-related features, move the sseu
> debugfs files under gt/.
> The sseu_status debugfs has also been kept at the top level as we do
> have tests that use it; it will be removed once we teach the tests to
>
== Series Details ==
Series: drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset() (rev2)
URL : https://patchwork.freedesktop.org/series/79255/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8715_full -> Patchwork_18112_full
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Pushed to dinq, thanks for all reviews
Manasi
On Wed, Jul 01, 2020 at 03:10:52PM -0700, Manasi Navare wrote:
> Based on the platform, Bspec expects us to wait or poll with
> timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active
> after enabling DDI_BUF_CTL.
>
> v2:
> * Based on
Pushed to dinq, thanks for the reviews
Manasi
On Wed, Jul 01, 2020 at 03:10:51PM -0700, Manasi Navare wrote:
> Modify the helper to add a fixed delay or poll with timeout
> based on platform specification to check for either Idle bit
> set (DDI_BUF_CTL is idle for disable case)
>
> v2:
> * Use
== Series Details ==
Series: Move some device capabilities under intel_gt (rev4)
URL : https://patchwork.freedesktop.org/series/78829/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8715_full -> Patchwork_18111_full
Summary
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Replace opencoded
i915_gem_object_pin_map() (rev2)
URL : https://patchwork.freedesktop.org/series/79250/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8715_full -> Patchwork_18109_full
Hi,
On 7/8/20 6:58 PM, Patchwork wrote:
== Series Details ==
Series: drm: Add privacy-screen class and connector properties
URL : https://patchwork.freedesktop.org/series/79259/
State : failure
== Summary ==
Applying: drm/connector: Fix kerneldoc warning
Using index info to reconstruct a
Hi Dave and Daniel,
A few patches this week while I'm covering Joonas vacation.
Most of the patches below also target stable trees (5.5+)
Here goes drm-intel-fixes-2020-07-08:
One display's fbc patch fixing fence_y_offset calculation
from Ville and 4 patches from Chris on GEM: 1 fixing a
Quoting Matthew Auld (2020-07-08 19:32:26)
> On Wed, 8 Jul 2020 at 14:48, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> > b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> > index 8291ede6902c..9fb06fcc8f8f 100644
> > ---
== Series Details ==
Series: dma-fence annotations, round 3 (rev4)
URL : https://patchwork.freedesktop.org/series/79212/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8715_full -> Patchwork_18108_full
Summary
---
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gem: Unpin idle contexts from
kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79260/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8715 -> Patchwork_18114
My laptop boots in EFI mode. It starts out using the efifb driver but
then switches over to i915drmfb. Relevant portions of the dmesg log:
[0.933464] efifb: probing for efifb
[0.933481] efifb: framebuffer at 0xe000, using 22500k, total 22500k
[0.933483] efifb: mode is
On Wed, 8 Jul 2020 at 14:48, Chris Wilson wrote:
>
> The GEM object is grossly overweight for the practicality of tracking
> large numbers of individual pages, yet it is currently our only
> abstraction for tracking DMA allocations. Since those allocations need
> to be reserved upfront before an
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gem: Unpin idle contexts from
kswapd reclaim
URL : https://patchwork.freedesktop.org/series/79260/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4ff593f626b9 drm/i915/gem: Unpin idle contexts from kswapd
Quoting Tvrtko Ursulin (2020-07-08 17:54:51)
>
> On 06/07/2020 07:19, Chris Wilson wrote:
> > @@ -662,18 +692,22 @@ static int eb_reserve(struct i915_execbuffer *eb)
> >* room for the earlier objects *unless* we need to defragment.
> >*/
> >
> > - if
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/79247/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8715_full -> Patchwork_18107_full
Summary
---
Some objects we map once during their construction, and then never
access their mappings again, even if they are kept around for the
duration of the driver. Keeping those pages mapped, often vmapped, is
therefore wasteful and we should release the maps as soon as we no
longer need them.
As we have a pin_map interface, that knows how to flush the data to the
device, use it. The only downside is that we keep the kmap around, as
once acquired we keep the mapping cached until the object's backing
store is released.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
We removed retiring requests from the shrinker in order to decouple the
mutexes from reclaim in preparation for unravelling the struct_mutex.
The impact of not retiring is that we are much less agressive in making
global objects available for shrinking, as such objects remain pinned
until they are
Last user removed, remove the get_dirty_page convenience function.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 14 --
2 files changed, 18 deletions(-)
diff --git
== Series Details ==
Series: series starting with [1/4] drm/i915: Move all FBC w/as to
.init_clock_gating()
URL : https://patchwork.freedesktop.org/series/79246/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8715_full -> Patchwork_18106_full
On Wed, 8 Jul 2020 at 14:48, Chris Wilson wrote:
>
> We removed retiring requests from the shrinker in order to decouple the
> mutexes from reclaim in preparation for unravelling the struct_mutex.
> The impact of not retiring is that we are much less agressive in making
> global objects available
On Thu, Jul 2, 2020 at 1:55 AM Lucas De Marchi wrote:
>
> From: Abdiel Janulgue
>
> Add the PCI ID for DG1, but keep it out of the table we use to register
> the driver. At this point we can't consider the driver ready to bind to
> the device since we basically miss support for everything. When
== Series Details ==
Series: drm: Add privacy-screen class and connector properties
URL : https://patchwork.freedesktop.org/series/79259/
State : failure
== Summary ==
Applying: drm/connector: Fix kerneldoc warning
Using index info to reconstruct a base tree...
M
On Wed, 8 Jul 2020 at 14:47, Chris Wilson wrote:
>
> Since the aliasing-ppgtt remains the default for gen6/gen7, it is worth
> optimising the ppgtt allocation for it. In this case, we do not need to
> flush the GGTT page directories entries as they are fixed during setup.
>
> Signed-off-by: Chris
On 06/07/2020 07:19, Chris Wilson wrote:
Our timeline lock is our defence against a concurrent execbuf
interrupting our request construction. we need hold it throughout or,
for example, a second thread may interject a relocation request in
between our own relocation request and execution in
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:
for_each_new_connector_in_state(>base, connector, ...
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also
Hi All,
Here is the privacy-screen related code which we discussed a while ago.
This series consists of a number of different parts:
1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties
2. Since on most devices the
Fix the following kerneldoc warning:
drivers/gpu/drm/drm_connector.c:2189:
warning: missing initial short description on line
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Signed-off-by: Hans
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.
This commit adds a privacy-screen class allowing the
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
On Wed, 8 Jul 2020 at 14:48, Chris Wilson wrote:
>
> Last user removed, remove the convenience function.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Wed, 8 Jul 2020 at 15:35, Chris Wilson wrote:
>
> Some objects we map once during their construction, and then never
> access their mappings again, even if they are kept around for the
> duration of the driver. Keeping those pages mapped, often vmapped, is
> therefore wasteful and we should
== Series Details ==
Series: drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset() (rev2)
URL : https://patchwork.freedesktop.org/series/79255/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8715 -> Patchwork_18112
On Wed, Jul 8, 2020 at 6:11 PM Daniel Vetter wrote:
>
> On Wed, Jul 8, 2020 at 5:05 PM Christian König
> wrote:
> >
> > Am 08.07.20 um 17:01 schrieb Daniel Vetter:
> > > On Wed, Jul 8, 2020 at 4:37 PM Christian König
> > > wrote:
> > >> Am 08.07.20 um 11:54 schrieb Daniel Vetter:
> > >>> On
On Wed, 8 Jul 2020 at 14:48, Chris Wilson wrote:
>
> As we have a pin_map interface, that knows how to flush the data to the
> device, use it. The only downside is that we keep the kmap around, as
> once acquired we keep the mapping cached until the object's backing
> store is released.
>
>
== Series Details ==
Series: drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset() (rev2)
URL : https://patchwork.freedesktop.org/series/79255/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0a11cb9ac305 drm/vgem: Replace opencoded version of
== Series Details ==
Series: Move some device capabilities under intel_gt (rev4)
URL : https://patchwork.freedesktop.org/series/78829/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8715 -> Patchwork_18111
Summary
---
On Wed, Jul 8, 2020 at 5:05 PM Christian König wrote:
>
> Am 08.07.20 um 17:01 schrieb Daniel Vetter:
> > On Wed, Jul 8, 2020 at 4:37 PM Christian König
> > wrote:
> >> Am 08.07.20 um 11:54 schrieb Daniel Vetter:
> >>> On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:
> Am
== Series Details ==
Series: Move some device capabilities under intel_gt (rev4)
URL : https://patchwork.freedesktop.org/series/78829/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: Move some device capabilities under intel_gt (rev4)
URL : https://patchwork.freedesktop.org/series/78829/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
81adaf361708 drm/i915: Convert device_info to uncore/de_read
e45d8bbcd7f5 drm/i915: Use the gt
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
In particular, vgem_gem_dumb_map() was trying to reject mmapping an
imported dmabuf by checking the existence of obj->filp. Unfortunately,
we always allocated an obj->filp, even if unused for an
== Series Details ==
Series: series starting with [1/7] drm/i915/gt: Replace opencoded
i915_gem_object_pin_map() (rev2)
URL : https://patchwork.freedesktop.org/series/79250/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8715 -> Patchwork_18109
== Series Details ==
Series: drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()
URL : https://patchwork.freedesktop.org/series/79255/
State : failure
== Summary ==
Applying: drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset()
Using index info to reconstruct a base
1 - 100 of 168 matches
Mail list logo
