On Tue, 03 Dec 2019, Anshuamn Gupta wrote:
> On 2019-11-28 at 16:05:03 +0200, Jani Nikula wrote:
>> On Mon, 18 Nov 2019, Anshuman Gupta wrote:
>> > Putting down the AUX power domain reference count in
>> > edp vdd off async sequence takes too much of time
>> > (relative to panel power cycle delay
On Mon, 02 Dec 2019, José Roberto de Souza wrote:
> Talked with HW team and this is a left over, driver should not
> program clockgating, dekel firmware will be reponsible for any
> clockgating programing.
>
> v2:
> Added WARN_ON
>
> BSpec issue: 20885
> BSpec: 49292
>
> Cc: Lucas De Marchi
> Cc:
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/display: Check the old state to
find port sync slave (rev2)
URL : https://patchwork.freedesktop.org/series/70320/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7467_full -> Patchwork_15550_full
==
Op 29-11-2019 om 12:37 schreef Ville Syrjälä:
> On Fri, Nov 29, 2019 at 09:48:45AM +0100, Maarten Lankhorst wrote:
>> Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
>>> On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankhorst wrote:
Op 27-11-2019 om 21:12 schreef Ville Syrjala:
> From: V
Add three basic tests for rc6 power status:
1. live_rc6_basic - simply checks if rc6 works when it's enabled
or stops when it's disabled.
2. live_rc6_threshold - rc6 should not work when the evaluation
interval is less than the threshold and should work otherwise.
3. live_rc6_busy - keeps
Op 28-11-2019 om 20:43 schreef Ville Syrjälä:
> On Thu, Nov 14, 2019 at 05:05:17PM +0100, Maarten Lankhorst wrote:
>> Make vdsc work when no output is enabled. The big joiner needs VDSC
>> on the slave, so enable it and set the appropriate bits.
>> Also update timestamping constants, because slave
On Mon, 02 Dec 2019, José Roberto de Souza wrote:
> This is better than keep those values in the code that you always
> need to check the DP spec to know what level of HBR it is.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 6 +-
> 1 file change
Quoting Nathan Chancellor (2019-12-03 05:05:22)
> On Fri, Nov 01, 2019 at 07:21:16PM +, Chris Wilson wrote:
> > Avoid
> >
> > drivers/gpu/drm/i915/i915_perf.c:2442:85: warning: dubious: x | !y
> >
> > simply by inverting the predicate and reversing the ternary.
> >
> > v2: More the long line
Op 28-11-2019 om 20:24 schreef Ville Syrjälä:
> On Thu, Nov 14, 2019 at 05:05:16PM +0100, Maarten Lankhorst wrote:
>> When the clock is higher than the dotclock, try with 2 pipes enabled.
>> If we can enable 2, then we will go into big joiner mode, and steal
>> the adjacent crtc.
>>
>> This only li
On Fri, 29 Nov 2019, Jani Nikula wrote:
> Use const for fb_ops to let us make the info->fbops pointer const in the
> future.
>
> Cc: linux-fb...@vger.kernel.org
> Cc: linux-o...@vger.kernel.org
> Reviewed-by: Daniel Vetter
> Signed-off-by: Jani Nikula
Pushed up to and including this patch to dr
Op 28-11-2019 om 20:04 schreef Ville Syrjälä:
> On Thu, Nov 14, 2019 at 05:05:15PM +0100, Maarten Lankhorst wrote:
>> Small changes to intel_dp_mode_valid(), allow listing modes that
>> can only be supported in the bigjoiner configuration, which is
>> not supported yet.
>>
>> eDP does not support b
== Series Details ==
Series: series starting with [1/2] drm/i915/dp: Define each HBR link rate
URL : https://patchwork.freedesktop.org/series/70323/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7467_full -> Patchwork_15551_full
Module-reload failure was now discussed on sync up meeting - not related to
this patch series.
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Patchwork [patchw...@emeril.freedesktop.
== Series Details ==
Series: drm/i915/selftests: add basic selftests for rc6 (rev3)
URL : https://patchwork.freedesktop.org/series/69825/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7467 -> Patchwork_15552
Summary
---
Op 18-11-2019 om 18:39 schreef Ville Syrjälä:
> On Thu, Nov 14, 2019 at 05:05:13PM +0100, Maarten Lankhorst wrote:
>> The members in hw.mode can be used from adjusted_mode as well,
>> use that when available.
>>
>> Some places that use hw.mode can be converted to use adjusted_mode
>> as well.
>>
>>
Some machines require ACPI for runtime resume, and ACPI is quite kmalloc
happy. We cannot handle kmalloc from inside the vm->mutex, as they are
used by the shrinker, and so we must ensure the global runtime-pm is
awake prior to unbinding to avoid the potential inversion.
<4> [57.121748] ==
And Haswell still occasionally forgets it is meant to be using a new
page directory, so repeat ourselves a little louder.
<7> [509.919864] heartbeat rcs0 heartbeat {prio:-2147483645} not ticking
<7> [509.919895] heartbeat Awake? 8
<7> [509.919903] heartbeat Barriers?: no
<7> [509.919912]
On Mon, 02 Dec 2019, "Souza, Jose" wrote:
> On Fri, 2019-11-29 at 08:22 +, Patchwork wrote:
>> == Series Details ==
>>
>> Series: series starting with [CI,1/5] drm/i915/psr: Add bits per
>> pixel limitation
>> URL : https://patchwork.freedesktop.org/series/70133/
>> State : failure
>>
>> =
Some machines require ACPI for runtime resume, and ACPI is quite kmalloc
happy. We cannot handle kmalloc from inside the vm->mutex, as they are
used by the shrinker, and so we must ensure the global runtime-pm is
awake prior to unbinding to avoid the potential inversion.
<4> [57.121748] ==
In order to avoid keeping a reference on the i915_vma (which is long
overdue!) we have to coordinate all the possible lifetimes and only use
the vma while we know it is alive. In this episode, we are reminded that
while idle, the closed vma are destroyed. So if the GT idles while we are
working wit
And Haswell still occasionally forgets it is meant to be using a new
page directory, so repeat ourselves a little louder.
<7> [509.919864] heartbeat rcs0 heartbeat {prio:-2147483645} not ticking
<7> [509.919895] heartbeat Awake? 8
<7> [509.919903] heartbeat Barriers?: no
<7> [509.919912]
Quoting Andi Shyti (2019-12-03 08:53:12)
> Add three basic tests for rc6 power status:
>
> 1. live_rc6_basic - simply checks if rc6 works when it's enabled
>or stops when it's disabled.
>
> 2. live_rc6_threshold - rc6 should not work when the evaluation
>interval is less than the threshol
Check the pending request submission is valid: that it at least has a
reference for the submission and that the request is on the active list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_
Only along the submission path can we guarantee that the locked request
is indeed from a foreign engine, and so the nesting of engine/rq is
permissible. On the submission tasklet (process_csb()), we may find
ourselves competing with the normal nesting of rq/engine, invalidating
our nesting. As we o
Check the pending request submission is valid: that it at least has a
reference for the submission and that the request is on the active list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_
Hi Chris,
> > }
> > +
> > +static bool test_rc6(struct intel_rc6 *rc6, bool enabled)
>
> I keep getting confused as to the meaning of the result, forgetting it
> changes based on bool enabled.
>
> Maybe u32 measure_rc6() and leave the pass/fail to the caller?
yes, I was thinking the same, it m
With the goal of removing the serialisation from around execbuf, we will
no longer have the privilege of there being a single execbuf in flight
at any time and so will only be able to inspect the user's flags within
the carefully controlled execbuf context. i915_gem_evict_for_node() is
the only use
For our convenience, and to avoid frequent allocations, we placed some
lists we use for execbuf inside the common i915_vma struct. As we look
to parallelise execbuf, such fields guarded by the struct_mutex BKL must
be pulled under local control. Instead of using the i915_vma as our
primary means of
As we no longer stash anything inside i915_vma under the exclusive
protection of struct_mutex, we do not need to revoke the i915_vma
stashes before dropping struct_mutex to handle pagefaults.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 --
1 fi
> > > }
> > > +
> > > +static bool test_rc6(struct intel_rc6 *rc6, bool enabled)
> >
> > I keep getting confused as to the meaning of the result, forgetting it
> > changes based on bool enabled.
> >
> > Maybe u32 measure_rc6() and leave the pass/fail to the caller?
thinking a bit better... what
On Fri, 22 Nov 2019, Lyude Paul wrote:
> Currently we always determine the initial panel brightness level by
> simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
> seems wrong though, because if the panel is not currently in DPCD
> control mode there's not really any reason wh
On Fri, 22 Nov 2019, Lyude Paul wrote:
> For eDP panels, it appears it's expected that so long as the panel is in
> DPCD control mode that the brightness value is never set to 0. Instead,
> if the desired effect is to set the panel's backlight to 0 we're
> expected to simply turn off the backlight
On Fri, 22 Nov 2019, Lyude Paul wrote:
> Turns out we actually already have some companies, such as Lenovo,
> shipping machines with AMOLED screens that don't allow controlling the
> backlight through the usual PWM interface and only allow controlling it
> through the standard EDP DPCD interface.
Quoting Andi Shyti (2019-12-03 12:32:24)
> > > > }
> > > > +
> > > > +static bool test_rc6(struct intel_rc6 *rc6, bool enabled)
> > >
> > > I keep getting confused as to the meaning of the result, forgetting it
> > > changes based on bool enabled.
> > >
> > > Maybe u32 measure_rc6() and leave th
Rather than assume if and only if the engine->default_state is not set
that the context is invalid, instead track when we know the context has
valid state -- either because we have copied the default_state or we
have completed a context switch to save the HW state.
Signed-off-by: Chris Wilson
---
On Fri, 22 Nov 2019, Lyude Paul wrote:
> Annoyingly, the VBT on the ThinkPad X1 Extreme 2nd Gen indicates that
> the system uses plain PWM based backlight controls, when in reality the
> only backlight controls that work are the standard VESA eDP DPCD
> backlight controls.
>
> Honestly, this makes
On Mon, Dec 02, 2019 at 10:03:38PM +, Souza, Jose wrote:
> On Thu, 2019-11-28 at 14:06 +0200, Ville Syrjälä wrote:
> > On Thu, Nov 28, 2019 at 01:14:37AM +, Souza, Jose wrote:
> > > On Wed, 2019-11-27 at 21:59 +0200, Ville Syrjälä wrote:
> > > > On Tue, Nov 26, 2019 at 08:30:31PM +, Sou
On Tue, 3 Dec 2019 at 10:13, Chris Wilson wrote:
>
> Some machines require ACPI for runtime resume, and ACPI is quite kmalloc
> happy. We cannot handle kmalloc from inside the vm->mutex, as they are
> used by the shrinker, and so we must ensure the global runtime-pm is
> awake prior to unbinding t
On Tue, Dec 03, 2019 at 09:45:19AM +0100, Maarten Lankhorst wrote:
> Op 29-11-2019 om 12:37 schreef Ville Syrjälä:
> > On Fri, Nov 29, 2019 at 09:48:45AM +0100, Maarten Lankhorst wrote:
> >> Op 28-11-2019 om 16:59 schreef Ville Syrjälä:
> >>> On Thu, Nov 28, 2019 at 04:48:04PM +0100, Maarten Lankho
== Series Details ==
Series: drm/i915/gem: Take runtime-pm wakeref prior to unbinding
URL : https://patchwork.freedesktop.org/series/70344/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bf52d20d7f97 drm/i915/gem: Take runtime-pm wakeref prior to unbinding
-:16: WARNING:COMMIT_L
On Tue, Dec 03, 2019 at 11:08:52AM +0200, Jani Nikula wrote:
> On Mon, 02 Dec 2019, José Roberto de Souza wrote:
> > This is better than keep those values in the code that you always
> > need to check the DP spec to know what level of HBR it is.
> >
> > Signed-off-by: José Roberto de Souza
> > --
Chris Wilson writes:
> Once inside a request, inside the timeline->mutex, pinning is verboten.
>
> <4> [896.032829] ==
> <4> [896.032831] WARNING: possible circular locking dependency detected
> <4> [896.032835] 5.4.0-rc8-CI-Patchwork_15533+ #1
On Mon, Dec 02, 2019 at 06:31:10PM -0800, José Roberto de Souza wrote:
> TGL has now a table for RBR and HBR and another table for HBR2 over
> combo phys. The HBR2 one has some small changes comparing to the ICL
> one, so adding two new tables and adding a function to return TGL
> combo phy tables.
Chris Wilson writes:
> It is not acceptable for context pinning to fail with -ENOSPC as we
> should always be able to make space in the GGTT. The only reason we may
> fail is that other "temporary" context pins are reserving their space
> and we need to wait for an available slot.
>
> Closes: htt
Quoting Mika Kuoppala (2019-12-03 13:24:03)
> Chris Wilson writes:
>
> > It is not acceptable for context pinning to fail with -ENOSPC as we
> > should always be able to make space in the GGTT. The only reason we may
> > fail is that other "temporary" context pins are reserving their space
> > an
On Tue, 3 Dec 2019 at 10:13, Chris Wilson wrote:
>
> In order to avoid keeping a reference on the i915_vma (which is long
> overdue!) we have to coordinate all the possible lifetimes and only use
> the vma while we know it is alive. In this episode, we are reminded that
> while idle, the closed vm
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Take runtime-pm wakeref prior
to unbinding
URL : https://patchwork.freedesktop.org/series/70347/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d45686935583 drm/i915/gem: Take runtime-pm wakeref prior to unbi
On Tue, Dec 03, 2019 at 10:18:51AM +0100, Maarten Lankhorst wrote:
> Op 28-11-2019 om 20:04 schreef Ville Syrjälä:
> > On Thu, Nov 14, 2019 at 05:05:15PM +0100, Maarten Lankhorst wrote:
> >> Small changes to intel_dp_mode_valid(), allow listing modes that
> >> can only be supported in the bigjoiner
Quoting Nick Desaulniers (2019-12-02 19:18:20)
> On Sat, Nov 23, 2019 at 12:05 PM Chris Wilson
> wrote:
> >
> > Quoting Nathan Chancellor (2019-11-23 19:53:22)
> > > -Wtautological-compare was recently added to -Wall in LLVM, which
> > > exposed an if statement in i915 that is always false:
> > >
On Fri, 2019-10-11 at 23:09 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> skl_commit_modeset_enables() is a bit of mess. Let's streamline
> it by simply tracking which pipes still need to be updated.
> As a bonus we get rid of the state->wm_results.dirty_pipes usage.
>
> Signed-off-by: V
== Series Details ==
Series: drm/i915/gem: Take runtime-pm wakeref prior to unbinding
URL : https://patchwork.freedesktop.org/series/70344/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7470 -> Patchwork_15553
Summary
-
On Mon, 2019-10-14 at 17:56 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's store the normal and IPS linetime watermarks individually,
> and while at it we'll pimp the register definitions as well.
>
> v2: Deal with gvt
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Stanislav Liso
== Series Details ==
Series: drm/i915/gt: Set the PD again for Haswell (rev3)
URL : https://patchwork.freedesktop.org/series/70321/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f505ce7b1c6d drm/i915/gt: Set the PD again for Haswell
-:22: WARNING:COMMIT_LOG_LONG_LINE: Possible
On 02/12/2019 11:08, Chris Wilson wrote:
Only signal the breadcrumbs from inside the irq_work, simplifying our
interface and calling conventions.
Making Icelake signaling latency look better? :) A few more words about
motivation would be good.
Regards,
Tvrtko
Signed-off-by: Chris Wilson
Quoting Tvrtko Ursulin (2019-12-03 14:06:51)
>
> On 02/12/2019 11:08, Chris Wilson wrote:
> > Only signal the breadcrumbs from inside the irq_work, simplifying our
> > interface and calling conventions.
>
> Making Icelake signaling latency look better? :) A few more words about
> motivation woul
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Take runtime-pm wakeref prior
to unbinding
URL : https://patchwork.freedesktop.org/series/70347/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7470 -> Patchwork_15554
===
== Series Details ==
Series: drm/i915/dsb: fix cmd_buf being wrongly set
URL : https://patchwork.freedesktop.org/series/70129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7434_full -> Patchwork_15475_full
Summary
---
== Series Details ==
Series: drm/i915/execlists: Add a couple more validity checks to
assert_pending()
URL : https://patchwork.freedesktop.org/series/70352/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK in
== Series Details ==
Series: series starting with [1/2] drm/i915: Drop inspection of execbuf flags
during evict (rev2)
URL : https://patchwork.freedesktop.org/series/70354/
State : failure
== Summary ==
Applying: drm/i915: Drop inspection of execbuf flags during evict
Applying: drm/i915/gem:
== Series Details ==
Series: drm/i915/gt: Set the PD again for Haswell (rev3)
URL : https://patchwork.freedesktop.org/series/70321/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7470 -> Patchwork_1
Summary
---
**
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Add a couple more
validity checks to assert_pending()
URL : https://patchwork.freedesktop.org/series/70353/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7470 -> Patchwork_15557
==
Check the pending request submission is valid: that it at least has a
reference for the submission and that the request is on the active list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_
Only along the submission path can we guarantee that the locked request
is indeed from a foreign engine, and so the nesting of engine/rq is
permissible. On the submission tasklet (process_csb()), we may find
ourselves competing with the normal nesting of rq/engine, invalidating
our nesting. As we o
And Haswell still occasionally forgets it is meant to be using a new
page directory, so repeat ourselves a little louder.
<7> [509.919864] heartbeat rcs0 heartbeat {prio:-2147483645} not ticking
<7> [509.919895] heartbeat Awake? 8
<7> [509.919903] heartbeat Barriers?: no
<7> [509.919912]
On 03/12/2019 11:53, Chris Wilson wrote:
Check the pending request submission is valid: that it at least has a
reference for the submission and that the request is on the active list.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
1 file changed, 3 insertions(+
From: Abdiel Janulgue
This is really just an alias of mmap_gtt. The 'mmap offset' nomenclature
comes from the value returned by this ioctl which is the offset into the
device fd which userpace uses with mmap(2).
mmap_gtt was our initial mmap_offset implementation, this extends
our CPU mmap suppo
== Series Details ==
Series: drm/i915/gt: Track the context validity explicitly
URL : https://patchwork.freedesktop.org/series/70356/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7470 -> Patchwork_15559
Summary
---
Quoting Chris Wilson (2019-12-03 15:26:31)
> Only along the submission path can we guarantee that the locked request
> is indeed from a foreign engine, and so the nesting of engine/rq is
> permissible. On the submission tasklet (process_csb()), we may find
> ourselves competing with the normal nest
On 03/12/2019 11:53, Chris Wilson wrote:
Only along the submission path can we guarantee that the locked request
is indeed from a foreign engine, and so the nesting of engine/rq is
permissible. On the submission tasklet (process_csb()), we may find
ourselves competing with the normal nesting of
Quoting Chris Wilson (2019-12-03 15:26:30)
> Check the pending request submission is valid: that it at least has a
> reference for the submission and that the request is on the active list.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
-Chris
___
Quoting Tvrtko Ursulin (2019-12-03 15:38:20)
>
> On 03/12/2019 11:53, Chris Wilson wrote:
> > Only along the submission path can we guarantee that the locked request
> > is indeed from a foreign engine, and so the nesting of engine/rq is
> > permissible. On the submission tasklet (process_csb()),
Quoting Chris Wilson (2019-12-03 15:26:31)
> Only along the submission path can we guarantee that the locked request
> is indeed from a foreign engine, and so the nesting of engine/rq is
> permissible. On the submission tasklet (process_csb()), we may find
> ourselves competing with the normal nest
In order to avoid keeping a reference on the i915_vma (which is long
overdue!) we have to coordinate all the possible lifetimes and only use
the vma while we know it is alive. In this episode, we are reminded that
while idle, the closed vma are destroyed. So if the GT idles while we are
working wit
== Series Details ==
Series: Refactor Gen11+ SAGV support (rev12)
URL : https://patchwork.freedesktop.org/series/68028/
State : failure
== Summary ==
Applying: drm/i915: Refactor intel_can_enable_sagv
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/display/intel_dis
On Mon, Dec 02, 2019 at 06:31:09PM -0800, José Roberto de Souza wrote:
> This is better than keep those values in the code that you always
> need to check the DP spec to know what level of HBR it is.
>
> Signed-off-by: José Roberto de Souza
I think there are a bunch of other places where we coul
On Mon, Dec 02, 2019 at 06:31:10PM -0800, José Roberto de Souza wrote:
> TGL has now a table for RBR and HBR and another table for HBR2 over
> combo phys. The HBR2 one has some small changes comparing to the ICL
> one, so adding two new tables and adding a function to return TGL
> combo phy tables.
Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/aty/atyfb.h | 2 +-
drivers/video/fbdev/aty/atyfb_base.c| 6 +++---
drivers/video/fbdev/aty/mach64_cursor.c |
Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/uvesafb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/
This is v3 of https://patchwork.freedesktop.org/series/70198/.
0day reported some build failures, and I needed to add patches 1-5 and 7
to address them. Patch 8 was amended accordingly (dropped some consts),
but the other patches remain the same from v2, except the ones I merged
already.
BR,
Jani
Now that we no longer modify the fbops, or hold non-const pointers to
it, we can make it const. After this, we can start making the fbops
const all over the place.
Cc: linux-fb...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
include/linux/fb.h | 2 +-
1 file changed
Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/nvidia/nvidia.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fb
Avoid modifying the fb_ops via info->fbops to let us make the pointer
const in the future. Drop the unnecessary EXPORT_SYMBOL() while at it.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/mb862xx/mb862xxfb.h | 2 +-
drivers/video/fbdev/mb862xx/mb862xxfb
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
v2: fix typo (Christophe de Dinechin)
Cc: Bruno Prémont
Cc: linux-in...@vger.kernel.org
Reviewed-by: Daniel Vetter
Acked-by: Bruno Prémont
Signed-off-by: Jani Nikula
---
drivers/hid/hid-picolcd_f
Use const for fb_ops to let us make the fbops struct const in the
future.
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/video/fbdev/intelfb/intelfb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/intelfb/intelfb.h
b/drivers/vide
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
v2: fix typo (Christophe de Dinechin)
Cc: Kirti Wankhede
Cc: k...@vger.kernel.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
samples/vfio-mdev/mdpy-fb.c | 2 +-
1 file changed, 1 in
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
This does not cover all drivers; some actually modify the fbops struct,
for example to adjust for different configurations, and others do more
involved things that I'd rather not touch in practically o
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Daniel Vetter
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 2 +-
drivers/gpu/drm/armada/armada_fbdev.c
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Cc: Miguel Ojeda Sandonis
Cc: Robin van der Gracht
Reviewed-by: Daniel Vetter
Reviewed-by: Miguel Ojeda
Acked-by: Robin van der Gracht
Signed-off-by: Jani Nikula
---
drivers/auxdisplay/cfag12864
Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.
Remove the redundant fbops assignments while at it.
v2:
- actually add const in vivid
- fix typo (Christophe de Dinechin)
Cc: Hans Verkuil
Cc: Andy Walls
Cc: linux-me...@vger.kernel.org
Cc: ivtv-de
On Tue, 03 Dec 2019, Jani Nikula wrote:
> This is v3 of https://patchwork.freedesktop.org/series/70198/.
>
> 0day reported some build failures, and I needed to add patches 1-5 and 7
Should be, patches 1-4 and 7.
> to address them. Patch 8 was amended accordingly (dropped some consts),
> but the
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Add a couple more
validity checks to assert_pending()
URL : https://patchwork.freedesktop.org/series/70375/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7471 -> Patchwork_15561
==
On Mon, Nov 25, 2019 at 10:43:52AM +0100, Daniel Vetter wrote:
> Hi all,
>
> This is prep work for some dma_resv series I'm tinkering with, but I
> figured good to split this out since good idea to land this no matter what
> exactly I'll end up creating in dma_resv. With these everything in
> driv
On Tue, Dec 03, 2019 at 06:38:43PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
>
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbdev/aty/atyfb.h | 2 +-
> drivers/video/fbd
== Series Details ==
Series: drm/i915/gt: Set the PD again for Haswell (rev4)
URL : https://patchwork.freedesktop.org/series/70321/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
16a289e5501c drm/i915/gt: Set the PD again for Haswell
-:22: WARNING:COMMIT_LOG_LONG_LINE: Possible
On Tue, Dec 03, 2019 at 06:38:44PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future. Drop the unnecessary EXPORT_SYMBOL() while at it.
>
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbd
On Tue, Dec 03, 2019 at 06:38:45PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
>
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbdev/nvidia/nvidia.c | 20 +++-
> 1
On Tue, Dec 03, 2019 at 06:38:46PM +0200, Jani Nikula wrote:
> Avoid modifying the fb_ops via info->fbops to let us make the pointer
> const in the future.
>
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbdev/uvesafb.c | 4 ++--
> 1 file changed, 2 inserti
On Tue, Dec 03, 2019 at 06:38:49PM +0200, Jani Nikula wrote:
> Use const for fb_ops to let us make the fbops struct const in the
> future.
>
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/video/fbdev/intelfb/intelfb.h | 2 +-
> 1 file changed, 1 insertion(+), 1 de
== Series Details ==
Series: drm/i915/gt: Set the PD again for Haswell (rev4)
URL : https://patchwork.freedesktop.org/series/70321/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7471 -> Patchwork_15562
Summary
---
**
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an L
1 - 100 of 165 matches
Mail list logo
