From: David Laight
> Sent: 16 January 2020 14:41
> > I'll do some measurements later this afternoon.
>
> This is an Ivy bridge cpu, so clflush (not clflushopt).
> With a cond_resched for every page I get:
> (Note these calls are every 10 seconds)
For comparison some times booted with the orig
From: Lukasz Luba
The overhauled Energy Model (EM) framework support also devfreq devices.
The unified API interface of the EM can be used in the thermal subsystem to
not duplicate code. The power table now is taken from EM structure and
there is no need to maintain calculation for it locally. In
From: Lukasz Luba
Drop the CPU specific interface with cpumask and switch to struct device.
The Energy Model framework supports both: CPUs and devfreq devices. The new
interface provides easy way to create a Energy Model (EM), which then might
be used in i.e. thermal subsystem.
Signed-off-by: Lu
drivers/gpu/drm/nouveau/dispnv04/arb.c: In function nv04_calc_arb:
drivers/gpu/drm/nouveau/dispnv04/arb.c:56:21: warning:
variable width set but not used [-Wunused-but-set-variable]
'width' is never used, so remove it.
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
drivers/gpu/drm/nouv
This patch continues the conversion of printk based logging macros to
the new struct drm_based logging macros in
drm/i915/display/intel_display.c.
This conversion was done using the following coccinelle script that
matches the existence of a straightforward struct drm_i915_private in
the functions:
Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
capture"), function 'i915_error_state_store' was defined and used with
only one parameter.
But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this function was defined
with two parameter.
This may lead compile error. This patch fix it
From: Chris Wilson
> Sent: 16 January 2020 12:29
>
> Quoting David Laight (2020-01-16 12:26:45)
> > However there is a call from __i915_gem_objet_set_pages() that
> > is preceded by a lockdep_assert_held() check - so mustn't sleep.
>
> That is a mutex; it's allowed to sleep. The might_sleep() he
commit 640ba2444fa9 ("drivers/video/pxa168fb.c: use devm_ functions")
left behind this, it can be removed.
Signed-off-by: YueHaibing
---
drivers/video/fbdev/pxa168fb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
index 706c
Mika Kuoppala writes:
>Subject: Re: [PATCH 1/2] drm/i915: Add mechanism to submit a context WA
>on ring submission
I forgot to add RFC into patch subject. This should carry
the RFC status as it is v2 on a RFC patch.
This patch squashes Chris Wilson's ctx switch optimization
and the development
This is the first patch that starts the conversion of the printk based
logging macros in drm/i915/display/intel_display.c to the new struct
drm_device based logging macros.
This conversion was done using the following coccinelle script that
matches based on the existence of a struct drm_i915_privat
From: Lukasz Luba
Hi all,
This patch set introduces support for devices in the Energy Model (EM)
framework.
It will unify the power model for thermal subsystem and make it simpler.
The 1st patch refactors EM framework and adds support for devices. The 2nd patch
changes dev_pm_opp_of_register_em
From: Lukasz Luba
Let Panfrost devfreq device use the Energy Model (EM). The EM can be used
in thermal subsystem (devfreq_cooling) for calculating the used power.
Signed-off-by: Lukasz Luba
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/d
Hi Greg,
On Thu, 2020-01-16 at 15:23 +0100, Greg KH wrote:
> On Thu, Jan 16, 2020 at 03:13:01PM +0100, Julian Stecklina wrote:
> > Hi Greg, Christoph,
> >
> > On Wed, 2020-01-15 at 16:22 +0100, Greg KH wrote:
> > > On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote:
> > > > Now that
This also replaces old artifacts with a correct one in drm_sched_entity_init()
declaration
Signed-off-by: Nirmoy Das
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
include/drm/gpu_scheduler.h | 10 +-
2 files changed, 6 insertions(+), 6 d
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuff
Hi!
Sorry for late reply.
Dne petek, 03. januar 2020 ob 22:19:01 CET je
roman.stratiie...@globallogic.com napisal(a):
> From: Roman Stratiienko
>
> DE3.0 VI layers supports plane-global alpha channel.
> DE2.0 FCC block have GLOBAL_ALPHA register that can be used as alpha source
> for blender.
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuff
From: Lukasz Luba
Add support of other devices into the Energy Model framework not only the
CPUs. Change the interface to be more unified which can handle other
devices as well.
Signed-off-by: Lukasz Luba
---
Documentation/power/energy-model.rst | 67 +++--
drivers/cpufreq/scmi-cpufreq.c
From: Randy Dunlap
Mark the nouveau@ mailing list as moderated for non-subscribers.
Signed-off-by: Randy Dunlap
---
MAINTAINERS |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20200116.orig/MAINTAINERS
+++ linux-next-20200116/MAINTAINERS
@@ -5315,7 +5315,7 @@ F:
On 1/16/20 1:17 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20200115:
>
> New tree: zonefs
>
> The sound-asoc tree lost its build failure.
>
> The net-next tree gained a build failure for which I reverted a commit.
>
> The keys tree still had build failures so I used the version fr
This series converts the printk based logging macros in
drm/i915/display/intel_display.c to the new struct drm_device based
logging macros. This change was split into four for manageability and
due to the size of drm/i915/display/intel_display.c.
Wambui Karuga (4):
drm/i915/display: conversion t
This patch continues the conversion of printk based logging macros to
the new struct drm_based logging macros in
drm/i915/display/intel_display.c.
This conversion was done using the following coccinelle script that
matches the existence of a straightforward struct drm_i915_private in
the functions:
This patch provides the final conversion of most of the printk based
logging macros instances in drm/i915/display/intel_display.c to the
struct drm_device based logging macros. The struct drm_i915_private
device is extracted from various intel types and used in the new logging
macros.
Signed-off-b
> I'll do some measurements later this afternoon.
This is an Ivy bridge cpu, so clflush (not clflushopt).
With a cond_resched for every page I get:
(Note these calls are every 10 seconds)
# tracer: function_graph
#
# CPU DURATION FUNCTION CALLS
# | | |
From: Chris Wilson
> Sent: 16 January 2020 07:40
> Quoting Daniel Vetter (2020-01-16 06:52:42)
> > On Wed, Jan 15, 2020 at 08:52:45PM +, Chris Wilson wrote:
> > > Since we may try and flush the cachelines associated with large buffers
> > > (an 8K framebuffer is about 128MiB, even before we tr
Hi Greg, Christoph,
On Wed, 2020-01-15 at 16:22 +0100, Greg KH wrote:
> On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote:
> > Now that the GVT interface to hypervisors does not depend on i915/GVT
> > internals anymore, we can move the headers to the global include/.
> >
> > This m
If CONFIG_IOMMU_API is n, build fails:
vers/gpu/drm/nouveau/nvkm/subdev/ltc/gp10b.c:37:9: error: implicit declaration
of function dev_iommu_fwspec_get; did you mean iommu_fwspec_free?
[-Werror=implicit-function-declaration]
spec = dev_iommu_fwspec_get(device->dev);
^~~
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning:
variable nv_connector set but not used [-Wunused-but-set-variable]
commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the
bpc we're using in nv50_head_atom") left behin
Hi Laurent,
(woops, forgot to press sent)
On Wed, Dec 18, 2019 at 12:13 AM Laurent Pinchart
wrote:
> On Tue, Dec 17, 2019 at 01:45:55PM +, Fabrizio Castro wrote:
> > this series adds support for dual-LVDS panel IDK-2121WR
> > from Advantech:
> > https://buy.advantech.eu/Displays/Embedded-LCD
Hi Fabrizio/Laurent/Geert.
(Thanks Geert, I recall I never replied to this mail).
On Fri, Jan 17, 2020 at 09:47:22AM +0100, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> (woops, forgot to press sent)
>
> On Wed, Dec 18, 2019 at 12:13 AM Laurent Pinchart
> wrote:
> > On Tue, Dec 17, 2019 at 01:45
On 09.01.2020 09:48, Tobias Schramm wrote:
> commit ff1e8fb68ea0 ("drm/bridge: analogix-anx78xx: Avoid drm_dp_link
> helpers")
> changed the link training logic to remove use of drm_dp_link helpers. However
> the new logic stores the maximum link rate in a u8, overflowing it.
> This commit changes
On 13.01.2020 14:45, Tomi Valkeinen wrote:
> Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
> max 165MHz.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 ++
> 1 file changed, 10
https://bugzilla.kernel.org/show_bug.cgi?id=206231
Bug ID: 206231
Summary: R9 280X low performance with all games
Product: Drivers
Version: 2.5
Kernel Version: 5.4.0-2-amd64
Hardware: x86-64
OS: Linux
Tree: Ma
On 07.01.2020 14:34, Bogdan Togorean wrote:
> ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
> 1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535 but on ADV7533 can be 1.2V
> or 1.8V and is configurable in a register.
>
> Signed-off-by: Bogdan Togorean
> ---
> drivers/gpu/drm/bridge/ad
On 17.01.2020 11:27, Andrzej Hajda wrote:
> On 07.01.2020 14:34, Bogdan Togorean wrote:
>> ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
>> 1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535 but on ADV7533 can be 1.2V
>> or 1.8V and is configurable in a register.
>>
>> Signed-off-by: Bo
On Thu, 16 Jan 2020, Lyude Paul wrote:
> Despite the fact that the VBT appears to have a field for specifying
> that a system is equipped with a panel that supports standard VESA
> backlight controls over the DP AUX channel, so far every system we've
> spotted DPCD backlight control support on doe
On 16/01/2020 02:15, Rob Herring wrote:
> From: Boris Brezillon
>
> With the introduction of per-FD address space, the same BO can be mapped
> in different address space if the BO is globally visible (GEM_FLINK)
> and opened in different context or if the dmabuf is self-imported. The
> current im
On Fri, 17 Jan 2020, Jani Nikula wrote:
> On Thu, 16 Jan 2020, Lyude Paul wrote:
>> Despite the fact that the VBT appears to have a field for specifying
>> that a system is equipped with a panel that supports standard VESA
>> backlight controls over the DP AUX channel, so far every system we've
>
Hi Zhang,
On Fri, Jan 17, 2020 at 03:34:36PM +0800, Zhang Xiaoxu wrote:
> Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
> capture"), function 'i915_error_state_store' was defined and used with
> only one parameter.
>
> But if no 'CONFIG_DRM_I915_CAPTURE_ERROR', this funct
Hi Tomi,
Thank you for the patch.
On Mon, Jan 13, 2020 at 03:45:28PM +0200, Tomi Valkeinen wrote:
> Add pixel clock limits to the driver as per TFP410 datasheet: min 25MHz,
> max 165MHz.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/ti-tfp410.c | 10 ++
> 1 file chan
On Fri, 17 Jan 2020, Andi Shyti wrote:
> Hi Zhang,
>
> On Fri, Jan 17, 2020 at 03:34:36PM +0800, Zhang Xiaoxu wrote:
>> Since commit 742379c0c4001 ("drm/i915: Start chopping up the GPU error
>> capture"), function 'i915_error_state_store' was defined and used with
>> only one parameter.
>>
>> But
Hi,
Static analysis with Coverity has detected a division by zero in the
following commit:
commit 5b5abe9526073ccbf3032d27b5864520829cdd9c
Author: Anthony Koo
Date: Mon Dec 9 17:26:34 2019 -0500
drm/amd/display: make PSR static screen entry within 30 ms
Specifically:
unsigned int
Hi
Am 16.01.20 um 00:18 schrieb Rodrigo Siqueira:
> Hi,
>
> Thanks for the patch, I reviewed and tested it. Everything looks fine
> for VKMS.
>
> Reviewed-by: Rodrigo Siqueira
> Tested-by: Rodrigo Siqueira
Thanks a lot.
Best regards
Thomas
>
> On 01/15, Thomas Zimmermann wrote:
>> VBLANK c
From: Colin Ian King
A for-loop is iterating from 0 up to 1000 however the loop variable count
is a u8 and hence not large enough. Fix this by making count an int.
Also remove the redundant initialization of count since this is never used
and add { } on the loop statement make the loop block cle
https://bugzilla.kernel.org/show_bug.cgi?id=206017
Paul (paul.e.hi...@outlook.com) changed:
What|Removed |Added
CC||paul.e.hi...@outlook.com
Thanks for the catch! Makes sense to skip disabled managers there, but I
wonder why it didn't cause a crash with amdgpu. Anyways looks good to me.
Acked-by: Mikita Lipski
On 1/16/20 8:58 PM, José Roberto de Souza wrote:
When a main MST port is disconnected drivers should call
drm_dp_mst_topol
On Thu, 16 Jan 2020, Wambui Karuga wrote:
> This series converts the printk based logging macros in
> drm/i915/display/intel_display.c to the new struct drm_device based
> logging macros. This change was split into four for manageability and
> due to the size of drm/i915/display/intel_display.c.
https://bugzilla.kernel.org/show_bug.cgi?id=206231
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
Hi Jani,
> >> Reported-by: Hulk Robot
> >
> > I've never been a fan of non human accounts, we had this discussion
> > already in a different mailing list. Could you please find a
> > different way of giving credit to your CI system?
>
> I don't actually mind for Reported-by credits. The history
On Thu, Jan 16, 2020 at 3:51 PM Bartlomiej Zolnierkiewicz
wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by
On Thu, Jan 16, 2020 at 3:52 PM Bartlomiej Zolnierkiewicz
wrote:
> Add COMPILE_TEST support to sh_mobile_lcdcfb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geer
On Fri, 17 Jan 2020, Andi Shyti wrote:
> Hi Jani,
>
>> >> Reported-by: Hulk Robot
>> >
>> > I've never been a fan of non human accounts, we had this discussion
>> > already in a different mailing list. Could you please find a
>> > different way of giving credit to your CI system?
>>
>> I don't a
Am 17.01.2020 14:33, schrieb Colin King:
> From: Colin Ian King
>
> A for-loop is iterating from 0 up to 1000 however the loop variable count
> is a u8 and hence not large enough. Fix this by making count an int.
> Also remove the redundant initialization of count since this is never used
> a
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #2 from kentosama (kentos...@whiteninjastudio.com) ---
Hello, with the radeonsi driver, the performance is lower than the amdgpu
driver. On the same scene in Tomb Raider, the graphics card displays ~ 10fps.
I have a lower score with g
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
radeonsi is the mesa OpenGL driver and runs over both radeon and amdgpu. Are
you actually using the radeon kernel driver?
--
You are receiving this mail because:
You are watching the
On Fri, Dec 13, 2019 at 3:09 PM wrote:
>
> From: Mikita Lipski
>
Hi Mikita,
Unfortunately this patch causes a crash on my i915 device when I
unplug my MST hub. The panic is below.
[ 38.514014] BUG: kernel NULL pointer dereference, address: 0030
[ 38.521801] #PF: supervisor read
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #4 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Alex Deucher from comment #3)
> Are you actually using the radeon kernel driver?
"DRM 2.50.0" says yes. :)
--
You are receiving this mail because:
You are watching the assi
On 1/17/20 10:09 AM, Sean Paul wrote:
On Fri, Dec 13, 2019 at 3:09 PM wrote:
From: Mikita Lipski
Hi Mikita,
Unfortunately this patch causes a crash on my i915 device when I
unplug my MST hub. The panic is below.
Hi Sean,
I thought this issue was fixed by Wayne Lin in
https://patchwo
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #5 from kentosama (kentos...@whiteninjastudio.com) ---
(In reply to Alex Deucher from comment #3)
> radeonsi is the mesa OpenGL driver and runs over both radeon and amdgpu.
> Are you actually using the radeon kernel driver?
Yes, i us
At the moment, video mode parameters like video=540x960,reflect_x,
(without rotation set) are not taken into account when applying the
mode in drm_client_modeset.c.
One of the reasons for this is that the calculation that
combines the panel_orientation with cmdline->rotation_reflection
does not ha
A rotation value should have exactly one rotation angle.
At the moment there is no validation for this when parsing video=
parameters from the command line. This causes problems later on
when we try to combine the command line rotation with the panel
orientation.
To make sure that we generate a va
At the moment, only DRM_MODE_ROTATE_180 is allowed when we try to apply
the rotation from the video mode parameters. It is also useful to allow
DRM_MODE_ROTATE_0 in case there is only a reflect option in the video mode
parameter (e.g. video=540x960,reflect_x).
DRM_MODE_ROTATE_0 means "no rotation"
On Fri, Jan 17, 2020 at 10:26 AM Mikita Lipski wrote:
>
>
>
> On 1/17/20 10:09 AM, Sean Paul wrote:
> > On Fri, Dec 13, 2019 at 3:09 PM wrote:
> >>
> >> From: Mikita Lipski
> >>
> >
> > Hi Mikita,
> > Unfortunately this patch causes a crash on my i915 device when I
> > unplug my MST hub. The pan
On Thu, 09 Jan 2020, Wambui Karuga wrote:
> This patchset continues the conversion to using the new struct
> drm_device based logging macros in drm/i915.
Pushed to drm-intel-next-queued, thanks for the patches.
BR,
Jani.
>
> Wambui Karuga (5):
> drm/i915: conversion to new logging macros in i
On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> From: Steven Price
>
> [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
This commit is effectively already in 5.4. Confusingly there were two
versions of this upstream:
52282163dfa6 ("drm/panfrost: Add missing check for
On Mon, Dec 9, 2019 at 12:56 AM Lin, Wayne wrote:
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Saturday, December 7, 2019 3:57 AM
> > To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> > amd-...@lists.freedesktop.org
> > Cc: Kazlauskas, Nicholas ; Wentland, Harry
> > ; Zuo
https://bugzilla.kernel.org/show_bug.cgi?id=206141
--- Comment #7 from Janpieter Sollie (janpieter.sol...@dommel.be) ---
Created attachment 286863
--> https://bugzilla.kernel.org/attachment.cgi?id=286863&action=edit
dmesg with 2 GPUs
OK, so this definitely looks like a HW failure,
also tried to
On Fri, Jan 17, 2020 at 04:12:27PM +, Steven Price wrote:
> On Thu, Jan 16, 2020 at 04:39:37PM +, Sasha Levin wrote:
> > From: Steven Price
> >
> > [ Upstream commit 52282163dfa651849e905886845bcf6850dd83c2 ]
>
> This commit is effectively already in 5.4. Confusingly there were two
> ver
Owner and user of tahiti parts on amdgpu with a state of the art gfx stack
poping in.
I own "rise of the tomb raider" which gnu/linux port is vulkan only, and vulkan
is only available with the "amdgpu" kernel module (as far as I know).
I have not bought "shadow of the tomb raider", which is vulka
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #6 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
Owner and user of tahiti parts on amdgpu with a state of the art gfx stack
poping in.
I own "rise of the tomb raider" which gnu/linux port is vulkan only, and vulkan
is only av
Hi Jitao.
Looks good, much better than the individual files.
Rob Herring is still listed as maintainer which I questioned in last
feedback.
With this resolved (kept only if Rob confirms), this is
Reviewed-by: Sam Ravnborg
On Thu, Jan 16, 2020 at 10:15:07AM +0800, Jitao Shi wrote:
> Add document
On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen wrote:
> This
>
> 1) Enables core DRM syncobj support.
> 2) Adds options to the submission ioctl to wait/signal syncobjs.
>
> Just like the wait fence fd, this does inline waits. Using the
> scheduler would be nice but I believe it is ou
Hi Jitao.
On Fri, Jan 17, 2020 at 07:08:17PM +0100, Sam Ravnborg wrote:
> Hi Jitao.
>
> Looks good, much better than the individual files.
> Rob Herring is still listed as maintainer which I questioned in last
> feedback.
>
> With this resolved (kept only if Rob confirms), this is
> Reviewed-by:
Hi Jitao.
Thanks for your perseverance on this.
With the minor issue on the binding file resolved everything is now fine
and patches are all applied to drm-misc-next.
Thanks,
Sam
On Thu, Jan 16, 2020 at 10:15:06AM +0800, Jitao Shi wrote:
> Changes since v8:
> - merge the panel document
On Fri, Jan 17, 2020 at 7:17 PM Jordan Crouse wrote:
>
> On Fri, Jan 17, 2020 at 12:04:17AM +0100, Bas Nieuwenhuizen wrote:
> > This
> >
> > 1) Enables core DRM syncobj support.
> > 2) Adds options to the submission ioctl to wait/signal syncobjs.
> >
> > Just like the wait fence fd, this does inli
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #7 from kentosama (kentos...@whiteninjastudio.com) ---
I noticed something strange. When I do the Tomb Raider benchmark, the GPU usage
is 100% and I hear the fans running at full speed after a few seconds.
The bench gives a result of
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #8 from kentosama (kentos...@whiteninjastudio.com) ---
(In reply to Sylvain BERTRAND from comment #6)
> Owner and user of tahiti parts on amdgpu with a state of the art gfx stack
> poping in.
>
> I own "rise of the tomb raider" which
Hi Icenowy
On Thu, Jan 16, 2020 at 11:36:31AM +0800, Icenowy Zheng wrote:
> This patchset tries to add support for the PineTab tablet from Pine64.
>
> As it uses a specific MIPI-DSI panel, the support of the panel should be
> introduced first, with its DT binding.
>
> Then a device tree is added
On Fri, Jan 17, 2020 at 04:34:27PM +0100, Stephan Gerhold wrote:
> At the moment, video mode parameters like video=540x960,reflect_x,
> (without rotation set) are not taken into account when applying the
> mode in drm_client_modeset.c.
>
> One of the reasons for this is that the calculation that
>
On Fri, Jan 17, 2020 at 07:50:12PM +0100, Sam Ravnborg wrote:
> Hi Icenowy
>
> On Thu, Jan 16, 2020 at 11:36:31AM +0800, Icenowy Zheng wrote:
> > This patchset tries to add support for the PineTab tablet from Pine64.
> >
> > As it uses a specific MIPI-DSI panel, the support of the panel should be
>
On Thu, Jan 16, 2020 at 03:49:07PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to arcfb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/Kconfig |2 +-
> 1 file changed, 1 ins
On Thu, Jan 16, 2020 at 03:53:20PM +0100, Bartlomiej Zolnierkiewicz wrote:
> * Add missing __iomem annotations where needed.
> * Make w100fb_probe() static.
> * Return NULL pointer (instead of using plain integer) in
> w100_get_xtal_tabl().
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by:
On Thu, Jan 16, 2020 at 03:53:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to w100fb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/Kconfig |2 +-
> 1 file changed, 1 in
On Thu, Jan 16, 2020 at 03:56:50PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
A
On Thu, Jan 16, 2020 at 03:58:08PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to wm8505fb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/Kconfig |2 +-
> 1 file changed, 1
On Thu, Jan 16, 2020 at 03:54:42PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Use ->screen_buffer instead of ->screen_base to fix sparse warnings.
>
> [ Please see commit 17a7b0b4d974 ("fb.h: Provide alternate screen_base
> pointer") for details. ]
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
A
Hi Bartlomiej
On Thu, Jan 16, 2020 at 03:08:55PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Force le32_to_cpup() argument to be of proper type (const __le32 *).
>
> Also add missing inline keyword to control_par_to_var() definition
> (to match function prototype).
>
> Signed-off-by: Bartlomiej Zo
On Fri, Jan 17, 2020 at 06:45:28PM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg
This seems to be from "shadow of the tomb raider" which I don't "own".
Do you "own" "rise of the tomb raider", the previous tomb raider game (which I
"own"
https://bugzilla.kernel.org/show_bug.cgi?id=206231
--- Comment #9 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) ---
On Fri, Jan 17, 2020 at 06:45:28PM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> screenshot : https://i.ibb.co/PrHj3hV/tombraider.jpg
This seems to be from "shadow of the
From: Sean Paul
Hey all,
Here's v3, which addresses all review comments in v2.
Sean
Sean Paul (12):
drm/i915: Fix sha_text population code
drm/i915: Clear the repeater bit on HDCP disable
drm/i915: WARN if HDCP signalling is enabled upon disable
drm/i915: Intercept Aksv writes in the au
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean Pa
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't do
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
https://patchwork.freedesk
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
Link
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being pla
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patc
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable HDCP
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean Pa
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Changes in v2:
- Added to the set in
Hi Bartlomiej
On Thu, Jan 16, 2020 at 03:08:57PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to controlfb driver for better compile
> testing coverage.
This is not a nice patch to add COMPILE_TEST support :-(
But I see why you do it.
I already spent too much time being side
1 - 100 of 131 matches
Mail list logo
