On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> This register contains how many blocks was sent in the past selective
> updates.
> Those registers are not kept set all the times but pulling it after
> flip
> can show that the expected values are set for the current frame and
>
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> PSR2 only trigger interruptions for AUX error, so let's not print
> useless information in debugsfs.
> Also adding a comment to intel_psr_irq_handler() about that.
The code still allows the enabling of interrupt debugging for PSR2.
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> The old debugfs fields was not following a naming partern and it was
> a bit confusing.
>
> So it went from:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink_Support: yes
> PSR mode: PSR1
> Enabled: yes
> Busy
On Tue, 2018-12-04 at 15:00 -0800, José Roberto de Souza wrote:
> For now PSR2 is still disabled by default for all platforms but is
> our intention to let debugfs to enable it for debug and tests
> proporses, so intel_psr2_enabled() that is also used by debugfs to
> decide if PSR2 is going to be
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Don't use DDB allocation when
choosing gen9 watermark method
URL : https://patchwork.freedesktop.org/series/53862/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5294_full -> Patchwork_11061_full
On Fri, 2018-09-28 at 21:04 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Consult the I2C_M_STOP flag to determine whether to set the MOT bit
> or
> not. Makes it possible to send multiple messages in one go with
> stop+start generated between the messages (as opposed nothing or
>
On 2018.12.10 16:41:24 -0800, Rodrigo Vivi wrote:
>
> On Fri, Dec 07, 2018 at 12:36:59PM +0800, Zhenyu Wang wrote:
> >
> > Hi,
> >
> > As I was hoping to possibly merge more new stuff for next kernel e.g
> > CFL support, etc, but seems those're still not stable enough so better
> > wait for
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Don't use DDB allocation when
choosing gen9 watermark method
URL : https://patchwork.freedesktop.org/series/53862/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5294 -> Patchwork_11061
== Series Details ==
Series: /drm/i915/hdmi: SCDC Scrambling enable without CTS mode (rev3)
URL : https://patchwork.freedesktop.org/series/50648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5293_full -> Patchwork_11060_full
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Don't use DDB allocation when
choosing gen9 watermark method
URL : https://patchwork.freedesktop.org/series/53862/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Don't use
The DDB allocation algorithm currently used by the driver grants each
plane a very small minimum allocation of DDB blocks and then divies up
all of the remaining blocks based on the percentage of the total data
rate that the plane makes up. It turns out that this proportional
allocation approach
The bspec gives an if/else chain for choosing whether to use "method 1"
or "method 2" for calculating the watermark "Selected Result Blocks"
value for a plane. One of the branches of the if chain is:
"Else If ('plane buffer allocation' is known and (plane buffer
allocation /
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_ types more
consistently for watermark code (v2)
URL : https://patchwork.freedesktop.org/series/53859/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5293_full -> Patchwork_11059_full
On Fri, Dec 07, 2018 at 12:36:59PM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> As I was hoping to possibly merge more new stuff for next kernel e.g
> CFL support, etc, but seems those're still not stable enough so better
> wait for next cycle, so sorry for the late.
If I understood correctly Jani
== Series Details ==
Series: /drm/i915/hdmi: SCDC Scrambling enable without CTS mode (rev3)
URL : https://patchwork.freedesktop.org/series/50648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5293 -> Patchwork_11060
On Mon, Dec 10, 2018 at 09:31:55PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 06, 2018 at 04:54:01PM -0800, Matt Roper wrote:
> > Try to be more consistent about intel_* types rather than drm_* types
> > for lower-level driver functions. While we're at it, let's also be more
> > consistent with
From: Clint Taylor
Setting the SCDC scrambling CTS mode causes HDMI Link Layer protocol tests
HF1-12 and HF1-13 to fail.
V2: Removed "Source Shall" entries to a new patch
V3: Rebase to drm-tip
Cc: Ville Syrjälä
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107895
Bugzilla:
== Series Details ==
Series: drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
URL : https://patchwork.freedesktop.org/series/53851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292_full -> Patchwork_11058_full
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_ types more
consistently for watermark code (v2)
URL : https://patchwork.freedesktop.org/series/53859/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5293 -> Patchwork_11059
On Mon, 2018-12-10 at 23:29 +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT
> > bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_ types more
consistently for watermark code (v2)
URL : https://patchwork.freedesktop.org/series/53859/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Use intel_
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Use intel_ types more
consistently for watermark code (v2)
URL : https://patchwork.freedesktop.org/series/53859/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9e0248a8ff62 drm/i915: Use intel_ types more
On Fri, Dec 07, 2018 at 10:28:39AM -0800, Anusha wrote:
> From: Anusha Srivatsa
>
> We have an update for HuC for BXT.
> Load the latest version.
>
> v2: Change the subject.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_huc_fw.c | 4 ++--
> 1 file
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions.
v2:
- Also drop the intel_crtc parameter from compute_intermediate_wm()
since we can just extract it from the crtc_state parameter. (Ville)
Signed-off-by: Matt Roper
Reviewed-by: Ville
Try to be more consistent about intel_* types rather than drm_* types
for lower-level driver functions. While we're at it, let's also be more
consistent with state variable naming (half of the platforms use the
name 'state' whereas the other half used 'crtc_state').
While we're touching these
On Mon, Dec 10, 2018 at 11:29:06PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> > The Write_Status_Update_Request I2C transaction requires the MOT bit to
> > be set, Change the logical AND to OR to fix what looks like a typo.
>
> It's not a
== Series Details ==
Series: drm/dp: Set the MOT bit for Write_Status_Update_Request transactions
URL : https://patchwork.freedesktop.org/series/53851/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292 -> Patchwork_11058
On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter wrote:
>
> Hi all,
>
> Just a small cleanup motivated by the last patch. After this series atomic
> drivers do no longer need the drm_crtc_helper.h header, and none of them
> use it. Except for the 2 that support both atomic and legacy kms in the
>
On Mon, Dec 10, 2018 at 01:07:49PM -0800, Dhinakaran Pandiyan wrote:
> The Write_Status_Update_Request I2C transaction requires the MOT bit to
> be set, Change the logical AND to OR to fix what looks like a typo.
It's not a type. We're just preserving MOT. What makes you think it
should always be
The Write_Status_Update_Request I2C transaction requires the MOT bit to
be set, Change the logical AND to OR to fix what looks like a typo.
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Ville Syrjälä
Fixes: 68ec2a2a2481 ("drm/dp: Use I2C_WRITE_STATUS_UPDATE to drain partial
I2C_WRITE
On Thu, Dec 06, 2018 at 03:55:41PM -0800, Matt Roper wrote:
> The DDB allocation algorithm currently used by the driver grants each
> plane a very small minimum allocation of DDB blocks and then divies up
> all of the remaining blocks based on the percentage of the total data
> rate that the plane
On Mon, 2018-12-10 at 18:39 +0200, Ville Syrjälä wrote:
> On Fri, Dec 07, 2018 at 12:45:25PM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-09-28 at 21:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We aren't supposed to force a stop+start between every i2c msg
> > >
On Thu, Dec 06, 2018 at 09:09:42AM -0800, Matt Roper wrote:
> SKL watermark calculations can and do trigger atomic transaction
> rejection if no valid set of watermarks can be found. This FIXME
> comment in the code hasn't been relevant for a very long time.
Identical patch already pushed.
>
>
On Thu, Dec 06, 2018 at 04:54:01PM -0800, Matt Roper wrote:
> Try to be more consistent about intel_* types rather than drm_* types
> for lower-level driver functions. While we're at it, let's also be more
> consistent with state variable naming (half of the platforms use the
> name 'state'
On Thu, Dec 06, 2018 at 04:54:00PM -0800, Matt Roper wrote:
> Try to be more consistent about intel_* types rather than drm_* types
> for lower-level driver functions.
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5 +-
> drivers/gpu/drm/i915/intel_display.c |
== Series Details ==
Series: mmu notifier debug checks v2 (rev2)
URL : https://patchwork.freedesktop.org/series/53828/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC kernel/sched/core.o
kernel/sched/core.c: In
On Fri, Dec 07, 2018 at 12:45:25PM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2018-09-28 at 21:03 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We aren't supposed to force a stop+start between every i2c msg
> > when performing multi message transfers. This should eg. cause
> > the
On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > I do not see any scheduler guys Cced and it would be really great to get
> > > their opinion here.
> > >
> > > On
On Mon, Dec 10, 2018 at 05:20:10PM +0100, Michal Hocko wrote:
> > OK, no real objections to the thing. Just so long we're all on the same
> > page as to what it does and doesn't do ;-)
>
> I am not really sure whether there are other potential users besides
> this one and whether the check as
On 2018年12月07日 18:29, Chris Wilson wrote:
Quoting Patchwork (2018-12-07 10:27:46)
== Series Details ==
Series: igt: add timeline test cases (rev2)
URL : https://patchwork.freedesktop.org/series/53743/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5281 -> IGTPW_2133
On Mon, Dec 10, 2018 at 11:03:53AM +0100, Daniel Vetter wrote:
> The correct way for legacy drivers to update properties that need to
> do a full modeset, is to do a full modeset.
>
> Note that we don't need to call the drm_mode_config_internal helper
> because we're not changing any of the
On Mon 10-12-18 16:22:53, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 04:01:59PM +0100, Michal Hocko wrote:
> > On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> > > On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > > > I do not see any scheduler guys Cced and it would be
On Mon, Dec 10, 2018 at 5:04 AM Daniel Vetter wrote:
>
> It's not a core function, and the matching atomic functions are also
> not in the core. Plus the suspend/resume helper is also already there.
>
> Needs a tiny bit of open-coding, but less midlayer beats that I think.
>
> Cc: Sam Bobroff
>
== Series Details ==
Series: mmu notifier debug checks v2
URL : https://patchwork.freedesktop.org/series/53828/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5292_full -> Patchwork_11056_full
Summary
---
**FAILURE**
On 09/11/2018 17:18, Tomasz Lis wrote:
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 a special batch buffer to be executed,
so the
On 07/11/2018 15:16, Tomasz Lis wrote:
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now published as part of bspec, and versioned. Entries
are supposed to never be modified, but new ones can be added. Adding
entries increases table version. The
On 07/11/2018 15:16, Tomasz Lis wrote:
The MOCS tables are going to be very similar across platforms.
To reduce the amount of copied code, this patch rips the common part and
puts it into a definition valid for all gen9 platforms.
v2: Made defines for or-ing flags. Renamed macros from
On Mon 10-12-18 15:47:11, Peter Zijlstra wrote:
> On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> > I do not see any scheduler guys Cced and it would be really great to get
> > their opinion here.
> >
> > On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > > In some special cases
== Series Details ==
Series: legacy helper cleanup
URL : https://patchwork.freedesktop.org/series/53819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292_full -> Patchwork_11055_full
Summary
---
**WARNING**
On Mon, Dec 10, 2018 at 03:13:37PM +0100, Michal Hocko wrote:
> I do not see any scheduler guys Cced and it would be really great to get
> their opinion here.
>
> On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock,
I do not see any scheduler guys Cced and it would be really great to get
their opinion here.
On Mon 10-12-18 11:36:39, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the
Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
a écrit :
>
> Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> a écrit :
> >
> > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > > Having the probe helper stuff (which pretty much everyone needs) in
> > > the drm_crtc_helper.h file
On Mon 10-12-18 11:36:38, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing i915 mmu
On Mon, Dec 10, 2018 at 11:03:57AM +0100, Daniel Vetter wrote:
> Doesn't do anything with atomic.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
>
On 10/12/2018 11:11, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers.
== Series Details ==
Series: mmu notifier debug checks v2
URL : https://patchwork.freedesktop.org/series/53828/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292 -> Patchwork_11056
Summary
---
**SUCCESS**
No
== Series Details ==
Series: legacy helper cleanup
URL : https://patchwork.freedesktop.org/series/53819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5292 -> Patchwork_11055
Summary
---
**SUCCESS**
No
== Series Details ==
Series: mmu notifier debug checks v2
URL : https://patchwork.freedesktop.org/series/53828/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
834029401554 mm: Check if mmu notifier callbacks are allowed to fail
-:56: WARNING:NO_AUTHOR_SIGN_OFF: Missing
On 04/12/2018 14:15, Chris Wilson wrote:
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY
== Series Details ==
Series: legacy helper cleanup
URL : https://patchwork.freedesktop.org/series/53819/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
21656459631c drm/ch7006: Stop using drm_crtc_force_disable
-:10: WARNING:TYPO_SPELLING: 'paramters' may be misspelled -
On 04/12/2018 14:15, Chris Wilson wrote:
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from
Le lun. 10 déc. 2018 à 11:24, Thierry Reding
a écrit :
>
> On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> > Having the probe helper stuff (which pretty much everyone needs) in
> > the drm_crtc_helper.h file (which atomic drivers should never need) is
> > confusing. Split them
Patches #1 and #3 are Reviewed-by: Christian König
Patch #2 is Acked-by: Christian König because
I can't judge if adding the counter in the thread structure is actually
a good idea.
In patch #4 I honestly don't understand at all how this stuff works, so
no-comment from my side on this.
On 2018-12-07 11:01 a.m., Chunming Zhou wrote:
> Signed-off-by: Chunming Zhou
> ---
> include/drm-uapi/drm.h | 33 ++
> lib/igt_syncobj.c| 204 +++
> lib/igt_syncobj.h| 19 +
> tests/gem_ctx_bad_exec | Bin 0 -> 1284384 bytes
Please run
git rm
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job
Hi all,
Here's v2 of my mmu notifier debug checks.
I think the last two patches could probably be extended to all callbacks,
but I'm not really clear on the exact rules. But happy to extend them if
there's interest.
This stuff helps us catch issues in the i915 mmu notifier implementation.
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them.
Just a bit of paranoia, since if we start pushing this deep into
callchains it's hard to spot all places where an mmu notifier
implementation might fail when it's not allowed to.
Inspired by some confusion we had discussing i915 mmu notifiers and
whether we could use the newly-introduced return
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not
On Mon, Dec 10, 2018 at 11:11:33AM +0100, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went
On 12/10/18 12:03 PM, Daniel Vetter wrote:
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.
To make sure I actually achieved the goal here I went through all
drivers. And indeed, all atomic drivers are now free of
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
lib/igt_core.c | 19 +++
lib/igt_core.h | 1 +
tests/i915/gem_shrink.c | 348
3 files changed, 368 insertions(+)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
tests/intel-ci/blacklist.txt | 1 +
tests/intel-ci/fast-feedback.testlist | 3 +++
2 files changed, 4 insertions(+)
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index 73d127603d28..8083efc407d4 100644
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.
To make sure I actually achieved the goal here I went through all
drivers. And indeed, all atomic drivers are now free of
== Series Details ==
Series: drm/dp-mst-helper: Remove hotplug callback
URL : https://patchwork.freedesktop.org/series/53192/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5217_full -> Patchwork_10942_full
Summary
---
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
It's a legacy kms only thing, good to hide it better now that all
those old drivers use the legacy crtc helpers directly.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 10 --
The correct way for legacy drivers to update properties that need to
do a full modeset, is to do a full modeset.
Note that we don't need to call the drm_mode_config_internal helper
because we're not changing any of the refcounted paramters.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc:
The correct way for legacy drivers to update properties that need to
do a full modeset, is to do a full modeset.
Note that we don't need to call the drm_mode_config_internal helper
because we're not changing any of the refcounted paramters.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
---
Doesn't do anything with atomic.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_display.c | 1 -
1 file changed, 1 deletion(-)
diff --git
Hi all,
Just a small cleanup motivated by the last patch. After this series atomic
drivers do no longer need the drm_crtc_helper.h header, and none of them
use it. Except for the 2 that support both atomic and legacy kms in the
same driver module (nouveau and amdgpu).
Last patch is a bit huge,
It's not a core function, and the matching atomic functions are also
not in the core. Plus the suspend/resume helper is also already there.
Needs a tiny bit of open-coding, but less midlayer beats that I think.
Cc: Sam Bobroff
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime
On Thu, Nov 29, 2018 at 01:30:59PM -0500, Lyude Paul wrote:
> Reviewed-by: Lyude Paul
Applied, thanks for your review.
-Daniel
>
> On Wed, 2018-11-28 at 23:12 +0100, Daniel Vetter wrote:
> > When everyone implements it exactly the same way, among all 4
> > implementations, there's not really a
On Sat, Dec 08, 2018 at 08:15:52PM +, Winkler, Tomas wrote:
>
> > On Fri, Dec 07, 2018 at 07:23:06PM +0530, C, Ramalingam wrote:
> > > Hi,
> > >
> > > In one of the offline discussion Tomas has shared his review comments on
> > > v8.
> >
> > Let's please have all review here on the mailing
On Sat, Dec 08, 2018 at 06:47:40PM +, Winkler, Tomas wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Friday, December 07, 2018 16:17
> > To: C, Ramalingam
> > Cc: Daniel Vetter ;
On Sun, 2018-12-09 at 12:18 +0100, Pavel Machek wrote:
> Hi!
>
> Another day, another problem... but this one is different from the
> previous hang, as machine survives.
Please, file a bug. It says so even in the splat...
Regards, Joonas
>
> Chromium was running with youtube video playing.
>
On Sat, 2018-12-08 at 12:24 +0100, Pavel Machek wrote:
> On Sat 2018-12-08 12:13:46, Pavel Machek wrote:
> > Hi!
> >
> > > > > > There's one similar for nouveau in Bugzilla, but it seems like a
> > > > > > genuine
> > > > > > memory corruption (1 bit flipped):
> > > > > >
> > > > > >
On 07/12/2018 20:57, Lucas De Marchi wrote:
On Fri, Dec 07, 2018 at 11:30:28AM +, Tvrtko Ursulin wrote:
On 07/12/2018 01:17, Lucas De Marchi wrote:
On Thu, Dec 6, 2018 at 4:37 AM Tvrtko Ursulin
wrote:
On 06/12/2018 06:11, Lucas De Marchi wrote:
Define IS_GEN() similarly to our
89 matches
Mail list logo
