On 7/23/2021 3:51 AM, Rob Clark wrote:
From: Rob Clark
This adds a few things to try and make frequency scaling better match
the workload:
1) Longer polling interval to avoid whip-lashing between too-high and
too-low frequencies in certain workloads, like mobile games which
throttle th
On 23/7/21 3:17 am, Zack Rusin wrote:
On 7/22/21 5:29 AM, Desmond Cheong Zhi Xi wrote:
drm_file.master should be protected by either drm_device.master_mutex
or drm_file.master_lookup_lock when being dereferenced. However,
drm_master_get is called on unprotected file_priv->master pointers in
vmw_
Hello Stephen,
On Fri, Jul 23, 2021 at 03:09:44PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the driver-core tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/gpu/drm/drm_dp_aux_bus.c:106:13: error: initialization of 'void
> (*)(struct devic
Quoting Kuogee Hsieh (2021-07-22 15:15:17)
> There is a scenario that dp cable is unplugged from DUT during system
> suspended will cause audio option state does not match real connection
> state. Fix this problem by Signaling audio plugged change with realtime
> connection status at dp_pm_resume(
Hi all,
After merging the driver-core tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/drm_dp_aux_bus.c:106:13: error: initialization of 'void
(*)(struct device *)' from incompatible pointer type 'int (*)(struct device *)'
[-Werror=incompatible-pointer-t
Hi Thomas,
Thank you for the patch.
On Tue, Jul 20, 2021 at 10:09:41AM +0200, Thomas Zimmermann wrote:
> Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers
> don't benefit from using it.
>
> v3:
> * return e
From: Dillon Min
This driver combines tiny/ili9341.c mipi_dbi_interface driver
with mipi_dpi_interface driver, and can support ili9341 with serial
mode or parallel rgb interface mode by register configuration.
Signed-off-by: Dillon Min
Reviewed-by: Linus Walleij
Reviewed-by: Jagan Teki
---
v3
From: Dillon Min
Since the compatible string defined from ilitek,ili9341.yaml is
"st,sf-tc240t-9370-t", "ilitek,ili9341"
so, append "ilitek,ili9341" to avoid the below dtbs_check warning.
arch/arm/boot/dts/stm32f429-disco.dt.yaml: display@1: compatible:
['st,sf-tc240t-9370-t'] is too short
Fix
From: Dillon Min
Add documentation for "ilitek,ili9341" panel.
Signed-off-by: Dillon Min
Reviewed-by: Linus Walleij
Reviewed-by: Rob Herring
Link:
https://lore.kernel.org/lkml/1626853288-31223-2-git-send-email-dillon.min...@gmail.com/
---
v3:
- collect reviewed-by tags from linus.
- add link
From: Dillon Min
Since the st,sf-tc240t-9370-t dts binding already exist in stm32f429-disco.dts
but, the panel driver didn't get accepted from mainline. it's time to submit
patch fot it.
This driver can support two different interface by different dts bindings:
- spi+dpi, use spi to configure re
From: Zheyu Ma
[ Upstream commit 9e5c772954406829e928dbe59891d08938ead04b ]
When calling ttm_range_man_fini(), 'man' may be uninitialized, which may
cause a null pointer dereference bug.
Fix this by checking if it is a null pointer.
This log reveals it:
[7.902580 ] BUG: kernel NULL pointe
From: Zheyu Ma
[ Upstream commit 9e5c772954406829e928dbe59891d08938ead04b ]
When calling ttm_range_man_fini(), 'man' may be uninitialized, which may
cause a null pointer dereference bug.
Fix this by checking if it is a null pointer.
This log reveals it:
[7.902580 ] BUG: kernel NULL pointe
On 2021-07-22 15:09, Stephen Boyd wrote:
Thank you for the comments .
Quoting maitr...@codeaurora.org (2021-07-22 14:33:43)
Thank you Stephen.
On 2021-07-22 13:31, Stephen Boyd wrote:
> Quoting maitreye (2021-07-21 16:19:40)
>> From: Maitreyee Rao
>>
>> Add trace points across the MSM DP drive
The pull request you sent on Fri, 23 Jul 2021 13:07:14 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-07-23
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8baef6386baaefb776bdd09b5c7630cf057c51c6
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On Sat 17 Jul 05:40 PDT 2021, Dmitry Baryshkov wrote:
> We are preparing to support two independent DSI hosts in the DSI/DPU
> code. To remove possible confusion (as both configurations can be
> referenced as dual DSI) let's rename old "dual DSI" (two DSI hosts
> driving single device, with clocks
Hi all,
On Fri, 23 Jul 2021 12:58:07 +1000 Stephen Rothwell
wrote:
>
> + #ifdef CONFIG_DRM_AMD_DC_HDCP
> + if (cp_psp && cp_psp->funcs.enable_assr) {
> + if (!cp_psp->funcs.enable_assr(cp_psp->handle, link)) {
> + /* since eDP implies ASSR on, change panel
>
Hi Linus,
Regular fixes pull request, a bunch of amdgpu fixes are the main thing
mostly for the new gpus. There is also some i915 reverts for older
changes that were having some unwanted side effects. One nouveau fix
for a report regressions, and otherwise just some misc fixes.
Dave.
drm-fixes-2
On Sun, Jul 18, 2021 at 10:22:14PM +0200, Sam Ravnborg wrote:
> Hi Oleksij,
> On Wed, Jul 14, 2021 at 06:53:49AM +0200, Oleksij Rempel wrote:
> > From: Sam Ravnborg
>
> The real author one these dts files are Juergen Borleis IIRC.
> I made some internal refactoring / renaming which is why I thing
Hi all,
Today's linux-next merge of the amdgpu tree got a conflict in:
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
between commit:
6be50f5d83ad ("drm/amd/display: Fix ASSR regression on embedded panels")
from the drm-fixes tree and commit:
fb85f280bf40 ("drm/amd/display: Re-enable
This is only used by GRAPHICS_VER == 6 and GRAPHICS_VER == 7. All other
recent platforms do not depend on this field, so it doesn't make much
sense to keep it generic like that. Instead, just do a mapping from
engine class to HW ID in the single place that is needed.
v2: use macros with the direct
This change enables probable eDP panels for all sc7180-trogdor
variants, leaving the existing panel as a fallback.
Though this won't make any immediate change, it paves the way for
supporting more second source panels on trogdor devices. It also
removes a "little white lie" which is that some trog
Up until now "desc" has usually pointed to one of the "static const"
objects defined in the panel-simple driver. Just storing a pointer to
one of these data elements made sense.
In a future patch to support probable eDP panels, however, it's
convenient to be able to modify the delays that the driv
As discussed in the patch ("dt-bindings: drm/panel-simple: Introduce
generic eDP panels") we can actually support probing eDP panels at
runtime instead of hardcoding what panel is connected. Add support to
the panel-simple driver for this.
We'll implement a solution like this:
* We'll read in two
In the case where we can read an EDID for a panel the only part of the
panel description that can't be found directly from the EDID is the
description of the delays. Let's break the delay structure out so that
we can specify just the delays for panels that are detected by EDID.
This is simple code
The simple-panel driver is for panels that are not hot-pluggable at
runtime. Let's keep our cached EDID around until driver unload.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-simple.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/
EDIDs have 32-bits worth of data which is intended to be used to
uniquely identify the make/model of a panel. This has historically
been used only internally in the EDID processing code to identify
quirks with panels.
We'd like to use this panel ID in panel-simple to identify which panel
is hooked
A future change wants to be able to read just block 0 of the EDID, so
break it out of drm_do_get_edid() into a sub-function.
This is intended to be a no-op change--just code movement.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/drm_edid.c | 62 +++---
1
eDP panels generally contain almost everything needed to control them
in their EDID. This comes from their DP heritage were a computer needs
to be able to properly control pretty much any DP display that's
plugged into it.
The one big issue with eDP panels and the reason that we need a panel
drive
The goal of this patch series is to move away from hardcoding exact
eDP panels in device tree files. As discussed in the various patches
in this series (I'm not repeating everything here), most eDP panels
are 99% probable and we can get that last 1% by allowing two "power
up" delays to be specifi
From: John Harrison
Some testing environments and some heavier tests are slower than
previous limits allowed for. For example, it can take multiple seconds
for the 'context has been reset' notification handler to reach the
'kill the requests' code in the 'active' version of the 'reset
engines' te
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
v2:
(Martin Peres / John H)
- Delete debug message when GuC is disabled by default on certain
platforms
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
Reviewed-
Implement a simple static mapping algorithm of the i915 priority levels
(int, -1k to 1k exposed to user) to the 4 GuC levels. Mapping is as
follows:
i915 level < 0 -> GuC low level (3)
i915 level == 0 -> GuC normal level (2)
i915 level < INT_MAX-> GuC high level(1)
i9
Requests may take slightly longer with GuC submission, let's increase
the timeouts in live_requests.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/selftests/i915_request.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
From: John Harrison
Added the scheduling policy parameters to the 'guc_info' debugfs state
dump.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 14 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_a
From: Rahul Kumar Singh
When GuC submission is enabled, the GuC controls engine resets. Rather
than explicitly triggering a reset, the driver must submit a hanging
context to GuC and wait for the reset to occur.
Signed-off-by: Rahul Kumar Singh
Signed-off-by: John Harrison
Signed-off-by: Matth
From: "Signed-off-by: Rahul Kumar Singh"
When GuC submission is enabled, the GuC controls engine resets. Rather
than explicitly triggering a reset, the driver must submit a hanging
context to GuC and wait for the reset to occur.
Signed-off-by: Rahul Kumar Singh
Signed-off-by: John Harrison
Sig
From: "Signed-off-by: John Harrison"
The driver must provide GuC with a list of mmio registers
that should be saved/restored during a GuC-based engine reset.
Unfortunately, the list must be dynamically allocated as its size is
variable. That means the driver must generate the list twice - once to
From: John Harrison
Changing the reset module parameter has no effect on a running GuC.
The corresponding entry in the ADS must be updated and then the GuC
informed via a Host2GuC message.
The new debugfs interface to module parameters allows this to happen.
However, connecting the parameter dat
The GuC can implement execution qunatums, detect hung contexts and
other such things but it requires the timer expired interrupt to do so.
Signed-off-by: Matthew Brost
CC: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4
1 file changed, 4 insertions(+)
From: John Harrison
Use the official driver default scheduling policies for configuring
the GuC scheduler rather than a bunch of hardcoded values.
v2:
(Matthew Brost)
- Move I915_ENGINE_WANT_FORCED_PREEMPTION to later patch
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed
This is required to allow backend specific cleanup
v2:
(John H)
- Rework commit message
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 3 ++-
drivers/gpu/drm/i915/i915_scheduler.h | 4 +---
drivers/gpu/drm/i915/i915_scheduler_
From: John Harrison
There are many ways in which the hangcheck selftest can fail. Very few
of them actually printed an error message to say what happened. So,
fill in the missing messages.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
Cc: Daniele Ceraolo
This adds GuC backend support for i915_request_cancel(), which in turn
makes CONFIG_DRM_I915_REQUEST_TIMEOUT work.
This implemenation makes use of fence while there is likely simplier
options. A fence was choosen because of another feature coming soon
which requires a user to block on a context un
From: John Harrison
In the case of a full GPU reset (e.g. because GuC has died or because
GuC's hang detection has been disabled), the driver can't rely on GuC
reporting the guilty context. Instead, the driver needs to scan all
active contexts and find one that is currently executing, as per the
We receive notification of an engine reset from GuC at its
completion. Meaning GuC has potentially cleared any HW state
we may have been interested in capturing. GuC resumes scheduling
on the engine post-reset, as the resets are meant to be transparent,
further muddling our error state.
There is o
From: John Harrison
The media watchdog mechanism involves GuC doing a silent reset and
continue of the hung context. This requires the i915 driver provide a
golden context to GuC in the ADS.
v2:
(Matthew Brost):
- Fix memory corruption in shmem_read
(John H)
- Use locals rather than define
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class when using GuC submission and
direct all physica
From: John Harrison
When GuC submission is enabled, the GuC controls engine resets. Rather
than explicitly triggering a reset, the driver must submit a hanging
context to GuC and wait for the reset to occur.
Conversely, one of the tests specifically sends hanging batches to the
engines but wants
GuC will notify the driver, via G2H, if it fails to
reset an engine. We recover by resorting to a full GPU
reset.
v2:
(John Harrison):
- s/drm_dbg/drm_err
Signed-off-by: Matthew Brost
Signed-off-by: Fernando Pacheco
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function to virtual
engine specific functions, set all other variables / functions to guc
versions, and set the engine mask to that of all the siblings.
v2: Update to work wit
Add disable GuC interrupts to intel_guc_sanitize(). Part of this
requires moving the guc_*_interrupt wrapper function into header file
intel_guc.h.
Signed-off-by: Matthew Brost
Cc: Daniele Ceraolo Spurio
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 16 +++
Move active request tracking to a backend vfunc rather than assuming all
backends want to do this in the manner. In the of case execlists /
ring submission the tracking is on the physical engine while with GuC
submission it is on the context.
Signed-off-by: Matthew Brost
Reviewed-by: John Harriso
When using GuC submission, if a context gets banned disable scheduling
and mark all inflight requests as complete.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context.h
From: John Harrison
Clear the 'disable resets' flag to allow GuC to reset hung contexts
(detected via pre-emption timeout).
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 3 +--
1 file changed, 1 insertion
From: John Harrison
It is impossible to seal all race conditions of resets occurring
concurrent to other operations. At least, not without introducing
excesive mutex locking. Instead, don't complain if it occurs. In
particular, don't complain if trying to send a H2G during a reset.
Whatever the H
If submission is disabled by the backend for any reason, reset the GPU
immediately in the heartbeat code as the backend can't be reenabled
until the GPU is reset.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 63 +++
The new GuC interface introduces an MMIO H2G command,
INTEL_GUC_ACTION_RESET_CLIENT, which is used to implement suspend. This
MMIO tears down any active contexts generating a context reset G2H CTB
for each. Once that step completes the GuC tears down the CTB
channels. It is safe to suspend once thi
GuC will issue a reset on detecting an engine hang and will notify
the driver via a G2H message. The driver will service the notification
by resetting the guilty context to a simple state or banning it
completely.
v2:
(John Harrison)
- Move msg[0] lookup after length check
v3:
(John Harrison)
Update the bonding extension to return -ENODEV when using GuC submission
as this extension fundamentally will not work with the GuC submission
interface.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +
1 file changed, 5 insertio
The remaining patches for basic GuC submission [1]. Need 4 more RB and
CI results to get this merged.
Signed-off-by: Matthew Brost
[1] https://patchwork.freedesktop.org/series/91840/
Daniele Ceraolo Spurio (1):
drm/i915/guc: Unblock GuC submission on Gen11+
John Harrison (11):
drm/i915/gu
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen in i915. Instead, requests are
submitted to
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check.
Future patches will offload the engine hang check to GuC but we will
continue to maintain this legacy path as a fallback and this code path
is also required
Hold a reference to the intel_context over life of an i915_request.
Without this an i915_request can exist after the context has been
destroyed (e.g. request retired, context closed, but user space holds a
reference to the request from an out fence). In the case of GuC
submission + virtual engine,
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> It's not used. Drivers should instead use the helpers anyway.
>
> Currently both vbox and i915 hand-roll this and it's not the greatest.
> vbox looks buggy, and i915 does a bit much that helpers would take
> care of I think.
>
> Also impro
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> We're trying to have a fairly strict split between core functionality
> that defines the uapi, including the docs, and the helper functions to
> implement it.
>
> Move drm_plane_enable_fb_damage_clips and associated kerneldoc into
> drm_pla
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> There's two stages of manual upload/invalidate displays:
> - just handling dirtyfb and uploading the entire fb all the time
> - looking at damage clips
>
> In the latter case we support it through fbdev emulation (with
> fb_defio), atomic p
This patch limits the size of total memory that can be requested in a
single allocation from the system heap. This would prevent a
buggy/malicious client from depleting system memory by requesting for an
extremely large allocation which might destabilize the system.
The limit is set to half the si
On 2021-07-22 10:53, Lyude Paul wrote:
On Tue, 2021-07-13 at 15:24 -0700, khs...@codeaurora.org wrote:
On 2021-07-07 01:37, Jani Nikula wrote:
> On Tue, 06 Jul 2021, Kuogee Hsieh wrote:
> > From: Rajkumar Subbiah
> >
> > Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing +
> >
Hi, Jason:
jason-jh.lin 於 2021年7月22日 週四 上午9:47寫道：
>
> The cursor plane should use the current plane state in atomic_async_update
> because it would not be the new plane state in the global atomic state
> since _swap_state happened when those hook are run.
>
> Fix cursor plane issue by below modif
From: Rob Clark
This adds a few things to try and make frequency scaling better match
the workload:
1) Longer polling interval to avoid whip-lashing between too-high and
too-low frequencies in certain workloads, like mobile games which
throttle themselves to 30fps.
Previously our polli
From: Rob Clark
In the next patch, it grows a bit more, so lets not duplicate the logic
in multiple places.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu
From: Rob Clark
Before we start adding more cleverness, split it into it's own file.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +-
drivers/gpu/drm/msm/msm_gpu.c | 116 +-
drivers/gpu/drm/m
From: Rob Clark
This is the outcome of trying to fix some bad gpu freq behavior seen in
some use-cases, in particular mobile games that throttle themselves to
30fps. With the existing tuning, we'd end up spending most of the time
that we should be running fast at a low freq, and most of the idle
There is a scenario that dp cable is unplugged from DUT during system
suspended will cause audio option state does not match real connection
state. Fix this problem by Signaling audio plugged change with realtime
connection status at dp_pm_resume() so that audio option will be in
correct state aft
https://bugzilla.kernel.org/show_bug.cgi?id=213823
--- Comment #5 from Bruno Pagani (bruno.n.pag...@gmail.com) ---
(In reply to Alex Deucher from comment #2)
> Please attach your full dmesg outputs. Can you bisect?
Done. Unfortunately no: I’ve never done so before, so while I expect to be
techni
Quoting maitr...@codeaurora.org (2021-07-22 14:33:43)
> Thank you Stephen.
>
> On 2021-07-22 13:31, Stephen Boyd wrote:
> > Quoting maitreye (2021-07-21 16:19:40)
> >> From: Maitreyee Rao
> >>
> >> Add trace points across the MSM DP driver to help debug
> >> interop issues.
> >>
> >> Changes in v4
https://bugzilla.kernel.org/show_bug.cgi?id=213823
--- Comment #4 from Bruno Pagani (bruno.n.pag...@gmail.com) ---
Created attachment 298011
--> https://bugzilla.kernel.org/attachment.cgi?id=298011&action=edit
dmesg 5.13
--
You may reply to this email to add a comment.
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=213823
--- Comment #3 from Bruno Pagani (bruno.n.pag...@gmail.com) ---
Created attachment 298009
--> https://bugzilla.kernel.org/attachment.cgi?id=298009&action=edit
dmesg 5.12
--
You may reply to this email to add a comment.
You are receiving this
On Thu, Jul 22, 2021 at 02:38:43PM -0700, Randy Dunlap wrote:
> On 7/22/21 2:29 PM, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > The VGA arbiter is really PCI-specific and doesn't depend on any GPU
> > things. Move it to the PCI subsystem.
> >
> > Signed-off-by: Bjorn Helgaas
> > ---
>
On Thu, Jul 22, 2021 at 02:50:24PM -0700, Daniele Ceraolo Spurio wrote:
>
>
>
> > > > @@ -1756,15 +1796,119 @@ static int guc_context_alloc(struct
> > > > intel_context *ce)
> > > > return lrc_alloc(ce, ce->engine);
> > > >}
> > > > +static void guc_context_set_prio(struct intel_guc
@@ -1756,15 +1796,119 @@ static int guc_context_alloc(struct intel_context *ce)
return lrc_alloc(ce, ce->engine);
}
+static void guc_context_set_prio(struct intel_guc *guc,
+struct intel_context *ce,
+u8 prio)
+{
+
On 7/22/21 2:29 PM, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> The VGA arbiter is really PCI-specific and doesn't depend on any GPU
> things. Move it to the PCI subsystem.
>
> Signed-off-by: Bjorn Helgaas
> ---
> drivers/gpu/vga/Kconfig | 19 ---
> drivers/gpu/vg
On Thu, Jul 22, 2021 at 01:26:30PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 7/16/2021 1:17 PM, Matthew Brost wrote:
> > Implement a simple static mapping algorithm of the i915 priority levels
> > (int, -1k to 1k exposed to user) to the 4 GuC levels. Mapping is as
> > follows:
> >
> > i915 l
Thank you Stephen.
On 2021-07-22 13:31, Stephen Boyd wrote:
Quoting maitreye (2021-07-21 16:19:40)
From: Maitreyee Rao
Add trace points across the MSM DP driver to help debug
interop issues.
Changes in v4:
- Changed goto statement and used if else-if
I think drm likes to see all the chang
From: Huacai Chen
Use the vga_default_device() interface consistently instead of directly
testing vga_default. No functional change intended.
[bhelgaas: split to separate patch and extended]
Link: https://lore.kernel.org/r/20210705100503.1120643-1-chenhua...@loongson.cn
Signed-off-by: Huacai Ch
From: Huacai Chen
Previously vga_arb_device_init() iterated through all VGA devices and
indicated whether legacy VGA routing to each could be controlled by an
upstream bridge.
But we determine that information in vga_arbiter_add_pci_device(), which we
call for every device, so we can log it ther
From: Huacai Chen
Needs a better subject and a commit log.
Link: https://lore.kernel.org/r/20210705100503.1120643-1-chenhua...@loongson.cn
---
drivers/pci/vgaarb.c | 158 ++-
1 file changed, 66 insertions(+), 92 deletions(-)
diff --git a/drivers/pci/vgaa
From: Huacai Chen
If there's no default VGA device, and we find a VGA device that owns the
legacy VGA resources, we make that device the default. Split this logic
out from vga_arbiter_add_pci_device() into a new function,
vga_arb_update_default_device().
[bhelgaas: split another piece to separa
From: Bjorn Helgaas
vga_arb_device_card_gone() has always been empty. Remove it.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
index e4153ab70481..c984c76b3
From: Huacai Chen
Move vga_arb_integrated_gpu() earlier in file to prepare for future patch.
No functional change intended.
[bhelgaas: split to separate patch]
Link: https://lore.kernel.org/r/20210705100503.1120643-1-chenhua...@loongson.cn
Signed-off-by: Huacai Chen
Signed-off-by: Bjorn Helgaas
From: Bjorn Helgaas
In struct vga_device, io_lock_cnt and mem_lock_cnt are unsigned, but we
previously printed them with "%d", the signed decimal format. Print them
with the unsigned format "%u" instead.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c | 2 +-
1 file changed, 1 insertion
From: Bjorn Helgaas
Per Documentation/process/license-rules.rst, the SPDX MIT identifier is
equivalent to including the entire MIT license text from
LICENSES/preferred/MIT.
Replace the MIT license text with the equivalent SPDX identifier.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/vgaarb.c
From: Bjorn Helgaas
The VGA arbiter is really PCI-specific and doesn't depend on any GPU
things. Move it to the PCI subsystem.
Signed-off-by: Bjorn Helgaas
---
drivers/gpu/vga/Kconfig | 19 ---
drivers/gpu/vga/Makefile | 1 -
drivers/pci/Kconfig
From: Bjorn Helgaas
This is a little bit of rework and extension of Huacai's nice work at [1].
It moves the VGA arbiter to the PCI subsystem, fixes a few nits, and breaks
a few pieces off Huacai's patch to make the main patch a little smaller.
That last patch is still not very small, and it nee
Quoting maitreye (2021-07-21 16:19:40)
> From: Maitreyee Rao
>
> Add trace points across the MSM DP driver to help debug
> interop issues.
>
> Changes in v4:
> - Changed goto statement and used if else-if
I think drm likes to see all the changelog here to see patch evolution.
>
> Signed-off-by:
On 7/16/2021 1:17 PM, Matthew Brost wrote:
Implement a simple static mapping algorithm of the i915 priority levels
(int, -1k to 1k exposed to user) to the 4 GuC levels. Mapping is as
follows:
i915 level < 0 -> GuC low level (3)
i915 level == 0 -> GuC normal level (2)
i91
Quoting Abhinav Kumar (2021-07-21 19:50:32)
> During board bringups its useful to have a DSI test pattern
> generator to isolate a DPU vs a DSI issue and focus on the relevant
> hardware block.
>
> To facilitate this, add an API which triggers the DSI controller
> test pattern. The expected output
Quoting Abhinav Kumar (2021-07-21 19:50:31)
> Update the DSI controller header XML file to add registers
> and bitfields to support rectangular checkered pattern
> generator.
>
> Signed-off-by: Abhinav Kumar
> ---
Reviewed-by: Stephen Boyd
https://bugzilla.kernel.org/show_bug.cgi?id=213823
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
Quoting Bjorn Andersson (2021-07-21 19:44:34)
> Some bootloaders set the widebus enable bit in the INTF_CONFIG register,
> but configuration of widebus isn't yet supported ensure that the
> register has a known value, with widebus disabled.
>
> Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driv
1 - 100 of 255 matches
Mail list logo
