Hi Linus,
On Fri, Jul 02, 2021 at 12:25:18AM +0200, Linus Walleij wrote:
> The macro mipi_dbi_command() does not report errors unless you wrap it
> in another macro to do the error reporting.
>
> Report a rate-limited error so we know what is going on.
>
> Drop the only user in DRM using
Hi Sam and Thierry,
On Tue, May 25, 2021 at 12:12 AM Jagan Teki wrote:
>
> ytc700tlag_05_201c panel support 8 bpc not 6 bpc as per
> recent testing in i.MX8MM platform.
>
> Fix it.
>
> Signed-off-by: Jagan Teki
> ---
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> 1 file changed, 1
Hi Linus,
On Thu, Jul 01, 2021 at 11:36:18PM +0200, Linus Walleij wrote:
> Improve the bindings and make them more usable:
>
> - Pick in spi-cpha and spi-cpol from the SPI node parent,
> this will specify that we are "type 3" in the device tree
> rather than hardcoding it in the operating
Hi Sam
Am 01.07.21 um 19:58 schrieb Sam Ravnborg:
Hi Thomas,
On Thu, Jul 01, 2021 at 02:43:12PM +0200, Thomas Zimmermann wrote:
Cleanup several nits in the driver's init code. Also move constant
data into the RO data segment. No functional changes.
Tested on mgag200 HW.
Thomas Zimmermann
On Mon, May 24, 2021 at 03:18:52PM +0200, Maxime Ripard wrote:
> The new gpiod interface takes care of parsing the GPIO flags and to
> return the logical value when accessing an active-low GPIO, so switching
> to it simplifies a lot the driver.
>
> Signed-off-by: Maxime Ripard
> ---
>
ext specific files
for 20210701
# good: [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13
git bisect start 'HEAD' 'v5.13'
# bad: [f63c4fda987a19b1194cc45cb72fd5bf968d9d90] Merge remote-tracking branch
'rdma/for-next'
git bisect bad f63c4fda987a19b1194cc45cb72fd5bf968d9d90
# good: [46bb5dd1d2a63e906e374e
Hi Steve,
> You didn't answer my previous question:
>
> > Is this device working with the kbase/DDK proprietary driver?
I don't know whether I used kbase/DDK,I only know I used the driver of
panfrost in linux 5.11.
> What you are describing sounds like a hardware integration issue, so
> it
On Thu, Jul 01, 2021 at 01:23:40PM -0700, Matt Roper wrote:
From: John Harrison
Increasing the engine count causes a couple of local array variables
to exceed the kernel stack limit. So make them dynamic allocations
instead.
Signed-off-by: John Harrison
Signed-off-by: Daniele Ceraolo Spurio
The macro mipi_dbi_command() does not report errors unless you wrap it
in another macro to do the error reporting.
Report a rate-limited error so we know what is going on.
Drop the only user in DRM using mipi_dbi_command() and actually checking
the error explicitly, let it use
On Thu, Jul 01, 2021 at 01:23:39PM -0700, Matt Roper wrote:
From: Venkata Sandeep Dhanalakota
In Gen12 there are various fuse combinations and in each configuration
vdbox engine may be connected to SFC depending on which engines are
available, so we need to set the SFC capability based on fuse
On Thu, Jul 01, 2021 at 01:23:38PM -0700, Matt Roper wrote:
From: Tvrtko Ursulin
On Xe_HP the fusing register is renamed and changed to have the "enable"
semantics, but otherwise remains compatible (mmio address, bitmask
ranges) with older platforms.
To simplify things we do not add a new
On Thu, Jul 01, 2021 at 01:23:50PM -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> XeHP SDV is a Intel® dGPU without display. This is just the definition
> of some basic platform macros, by large a copy of current state of
> Tigerlake which does not reflect the end state of this platform.
>
On Thu, Jul 01, 2021 at 01:23:57PM -0700, Matt Roper wrote:
> The RP_STATE_CAP register is no longer part of the MCHBAR on XEHPSDV; this
> register is now a per-tile register at GTTMMADDR offset 0x250014.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Matt Roper
> Signed-off-by: Lucas De Marchi
Improve the bindings and make them more usable:
- Pick in spi-cpha and spi-cpol from the SPI node parent,
this will specify that we are "type 3" in the device tree
rather than hardcoding it in the operating system.
- Drop the u32 ref from the SPI frequency: comes in from
the SPI host
Hello,
first of all: thanks for your patch and sorry for being late with my
review question.
On Fri, Jun 18, 2021 at 7:28 AM Jiajun Cao wrote:
>
> Fix a potential NULL pointer exception when meson_drv_unbind()
> attempts to operate on the driver_data priv which may be NULL.
> Add a null pointer
Am 2021-07-01 um 4:15 p.m. schrieb Linus Torvalds:
> On Wed, Jun 30, 2021 at 9:34 PM Dave Airlie wrote:
>> Hi Linus,
>>
>> This is the main drm pull request for 5.14-rc1.
>>
>> I've done a test pull into your current tree, and hit two conflicts
>> (one in vc4, one in amdgpu), both seem pretty
On 2021-06-09 14:17, Dmitry Baryshkov wrote:
Move setting up encoders from set_encoder_mode to
_dpu_kms_initialize_dsi() / _dpu_kms_initialize_displayport(). This
allows us to support not only "single DSI" and "dual DSI" but also "two
independent DSI" configurations. In future this would also
On Wed 30 Jun 19:00 CDT 2021, Dmitry Baryshkov wrote:
> None of supported devies uses "gdsc" regulator for DSI. GDSC support is
> now implemented as a power domain. Drop old code and config handling
> gdsc regulator requesting and enabling.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by:
From: Stuart Summers
Xe_HP changes the format of the context ID from past platforms.
Cc: Robert M. Fosha
Signed-off-by: Stuart Summers
Signed-off-by: Umesh Nerlige Ramappa
Signed-off-by: Matt Roper
---
.../drm/i915/gt/intel_execlists_submission.c | 74 ---
DG2 does not use system DRAM information for BW_BUDDY programming or
watermark workarounds, so there's no need to read this out at startup.
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_dram.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
DG2 has no shared DPLL's or DDI clock muxing. The Port PLL is embedded
within the PHY.
Bspec: 54032
Bspec: 54034
Cc: Lucas De Marchi
Cc: Mohammed Khajapasha
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +++---
On DG2 we're supposed to just wait 600us after programming the well
before moving on; there won't be an ack from the hardware.
Bspec: 49296
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_display_power.c | 16
.../gpu/drm/i915/display/intel_display_power.h | 6
From: José Roberto de Souza
PSR2 is not supported on DG2.
Cc: Caz Yokoyama
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_psr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Gwan-gyeong Mun
The PSR enable/disable sequences now require that we program an extra
register in the PHY to adjust the lane disable power setting.
Bspec: 49274
Bspec: 53885
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
Signed-off-by: Gwan-gyeong Mun
---
From: Ankit Nautiyal
Add the functions to configure HDMI2.1 pcon for DG2, before DP link
training.
Signed-off-by: Ankit Nautiyal
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Initialization of the PHY is handled by the hardware/firmware, but the
driver should wait up to 25ms for the PHY to report that its calibration
has completed.
Bspec: 49189
Bspec: 50107
Cc: Matt Atwood
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_display_power.c| 5 +
From: Tvrtko Ursulin
On Xe_HP the fusing register is renamed and changed to have the "enable"
semantics, but otherwise remains compatible (mmio address, bitmask
ranges) with older platforms.
To simplify things we do not add a new register definition but just stop
inverting the fusing masks
Although the bspec labels four of DG2's outputs as "combo PHY," the
underlying PHYs in both cases are actually Synopsys PHYs that are
programmed completely differently than the traditional Intel "combo" PHY
units. As such, we don't want intel_phy_is_combo to take us down legacy
programming paths,
At the moment we don't have a proper algorithm that can be used to
calculate PHY settings for arbitrary HDMI link rates. The PHY tables
here should support the regular modes of real-world HDMI monitors.
Bspec: 54032
Cc: Matt Atwood
Signed-off-by: Matt Roper
Signed-off-by: Vandita Kulkarni
---
From: Akeem G Abodunrin
New LRI register offsets were introduced for DG2, this patch adds
those extra registers, and create new register table for setting offsets
to compare with HW generated context image - especially for gt_lrc test.
Also updates general purpose register with scratch offset
Vswing programming for SNPS PHYs is just a single step -- look up the
value that corresponds to the voltage level from a table and program it
into the SNPS_PHY_TX_EQ register.
Bspec: 53920
Cc: Matt Atwood
Signed-off-by: Matt Roper
Signed-off-by: Jani Nikula
---
DG2 has some changes to the expected modesetting sequences when compared
to gen12. Adjust our driver logic accordingly. Although the DP
sequence is pretty similar to TGL's, there are some steps that change,
so let's split the handling for that out into a separate function.
Bspec: 54128
Cc:
From: John Harrison
Xe_HP can have a lot of extra media engines. This patch adds the basic
definitions for them.
Cc: Tvrtko Ursulin
Signed-off-by: John Harrison
Signed-off-by: Tomas Winkler
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 ++-
Bspec: 45101, 45427
Cc: Ramalingam C (v5)
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 35 +++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index
From: Lucas De Marchi
Instead of maintaining the same if ladder in 3 different places, add a
function to read RP_STATE_CAP.
Signed-off-by: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 8 +++-
drivers/gpu/drm/i915/gt/intel_rps.c | 17
From: Anusha Srivatsa
Set compress BPP in kernel while connector DP or eDP
Cc: Vandita Kulkarni
Cc: Navare Manasi D
Signed-off-by: Anusha Srivatsa
Signed-off-by: Patnana Venkata Sai
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-
1 file
From: Anusha Srivatsa
DSC can be supported per DP connector. This patch creates
a per connector debugfs node to expose the Input and
Compressed BPP.
The same node can be used from userspace to force
DSC to a certain BPP.
force_dsc_bpp is written through this debugfs
node to force DSC BPP to
Define and initialize the MMIO ranges for which XeHP SDV requires MSLICE
and LNCF steering.
Bspec: 66534
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 19 ++-
From: Lucas De Marchi
Like DG1, XeHP SDV doesn't have LLC/eDRAM control values due to being a
dgfx card. XeHP SDV adds 2 more bits: L3_GLBGO to "push the Go point to
memory for L3 destined transaction" and L3_LKP to "enable Lookup for
uncacheable accesses".
Bspec: 45101
Cc: Daniele Ceraolo
The RP_STATE_CAP register is no longer part of the MCHBAR on XEHPSDV; this
register is now a per-tile register at GTTMMADDR offset 0x250014.
Cc: Rodrigo Vivi
Signed-off-by: Matt Roper
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4 +++-
DG2 extends our DDB to four DBuf slices; pipes A+B only have access to
the first two slices, whereas pipes C+D only have access to the second
two.
Confusingly, our bspec decided to switch from 1-based numbering
of dbuf slices (S1, S2) to 0-based numbering (S0, S1, S2, S3) in
Display13. At the
Although the BW_BUDDY registers still exist, they are not used for
anything on DG2. This change is expected to hold true for future dgpu's
too.
Bspec: 49218
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display_power.c | 4
1 file changed, 4 insertions(+)
diff --git
For tgl+, the per-context setting of MI_MODE[12] determines whether
the bits of a nested MI_BATCH_BUFFER_START instruction should be
interpreted in the traditional manner or whether they should
instead use a new tgl+ meaning that breaks backward compatibility, but
allows nesting into 3rd-level
The DG2 forcewake table is very similar to the one used by XeHP SDV (and
both platforms are even presented as a single table in the bspec). For
the most part DG2 starts using a few additional ranges that were
'reserved' on XeHP SDV and stops using some others. However there is a
single range
DG2 doesn't have a SAGV or QGV points that determine memory bandwidth.
Instead it has a constant amount of memory bandwidth available to
display that does not need to be reduced based on the number of active
planes.
For simplicity, we'll just modify driver initialization to create a
single dummy
From: John Harrison
Increasing the engine count causes a couple of local array variables
to exceed the kernel stack limit. So make them dynamic allocations
instead.
Signed-off-by: John Harrison
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
DG2 has outputs on DDI A-D attached to what the bspec diagram shows as
"Combo PHY A-D." Note that despite being labelled "combo" the PHYs on
these outputs are Synopsys PHYs rather than traditional Intel combo PHY
technology.
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
---
Xe_HPG adds some additional INSTDONE_GEOM debug registers; the Mesa team
has indicated that having these reported in the error state would be
useful for debugging GPU hangs. These registers are replicated per-DSS
with gslice steering.
Cc: Lionel Landwerlin
Signed-off-by: Matt Roper
---
From: Daniele Ceraolo Spurio
Xe_HP is more modular then its predecessors and as a consequence it has
more types of replicated registers. As with l3bank regions on previous
platforms, we may need to explicitly re-steer accesses to these new
types of ranges at runtime if we can't find a single
As with DG1, DG2 has an ICL-style south display interface provided on
the same PCI device. Add a fake PCH to ensure DG2 takes the appropriate
codepaths for south display handling.
Bspec: 54871, 50062, 49961, 53673
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
Signed-off-by: Aditya Swarup
Due to the removal of legacy slices and the transition to a
gslice/cslice/mslice/etc. design, we'll internally store all DSS under
"slice0."
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 5 -
drivers/gpu/drm/i915/gt/intel_sseu.h | 2 +-
From: Paulo Zanoni
The current interrupt handler is getting increasingly complicated and
Xe_HP changes will bring even more complexity. Let's split off a new
interrupt handler starting with DG1 (i.e., when the master tile
interrupt register was added to the design) and use that as the basis
for
We no longer have traditional slices on Xe_HP platforms, but the
INSTDONE registers are replicated according to gslice representation
which is similar. We can mostly re-use the existing instdone code with
just a few modifications:
* Create an alternate instdone loop macro that will iterate over
From: Matthew Auld
Xe_HP no longer has "slices" in the same way that old platforms did.
There are new concepts (gslices, cslices, mslices) that apply in various
contexts, but for the purposes of fusing slices no longer exist and we
just have one large pool of dual-subslices (DSS) to work with.
DG2's SNPS PHYs incorporate a dedicated port PLL called MPLLB which
takes the place of the shared DPLLs we've used on past platforms. Let's
add the MPLLB programming sequences; they'll be plugged into the rest of
the code in future patches.
Bspec: 54032
Bspec: 53881
Cc: Lucas De Marchi
Note that DG2 only has a single possible refclk frequency (38.4 MHz).
Bspec: 54034
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 24 --
1 file changed, 22 insertions(+), 2 deletions(-)
diff
From: Prathap Kumar Valsan
The layout of some engine contexts has changed on Xe_HP. Define the new
offsets.
Bspec: 45585, 46256
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Ramalingam C
Signed-off-by: Venkata Ramana Nayana
Signed-off-by: Akeem G Abodunrin
Signed-off-by: Matt Roper
From: Animesh Manna
In verify_mpllb_state() encoder is retrieved from best_encoder
of connector_state. As there will be only one connector_state
for bigjoiner and checking encoder may not be needed for
bigjoiner-slave. This code path related to mpll is done on dg2
and need this fix to avoid null
DG2 supports compute DSS and has the same maximum number of DSS and EU
as XeHP SDV.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
From: Lucas De Marchi
XeHP SDV is a Intel® dGPU without display. This is just the definition
of some basic platform macros, by large a copy of current state of
Tigerlake which does not reflect the end state of this platform.
Bspec: 44467, 48077
Cc: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
Although DG2_G10 platforms will always have all SQIDI's present and
don't need steering for registers in a SQIDI MMIO range, this isn't true
for DG2_G11 platforms; only SQIDI's 2 and 3 can be used on those.
We handle SQIDI ranges a bit differently from other types of explicit
steering. The SQIDI
From: Stuart Summers
Starting in XeHP, the concept of slice has been removed in favor of
DSS (Dual-Subslice) masks for various workload types. These workloads have
been divided into those enabled for geometry and those enabled for compute.
i915 currently maintains a single set of S/SS/EU masks
From: John Harrison
Xe_HP can have a lot of extra media engines. This patch adds the reset
support for them.
Signed-off-by: John Harrison
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_reset.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 8
2 files changed, 14
DG2's replicated register ranges are almost the same at XeHP SDV with
the exception of one LNCF sub-range that switches to gslice steering.
We can re-use the XeHP SDV mslice steering table and just provide a
DG2-specific LNCF steering table.
Bspec: 66534
Cc: Daniele Ceraolo Spurio
Signed-off-by:
DG2 has Xe_LPD display (version 13) and Xe_HPG (version 12.55) graphics.
There are two variants (treated as subplatforms in the code): DG2-G10
and DG2-G11 that require independent programming in some areas (e.g.,
workarounds).
Bspec: 44472, 44474, 46197, 48028, 48077
Cc: Anusha Srivatsa
From: Lucas De Marchi
Besides the arch version returned by GRAPHICS_VER(), new platforms
contain a "release id" to make clear the difference from one platform to
another. Although for the first ones we may use them as if they were a
major/minor version, that is not true for all platforms: we may
From: Venkata Sandeep Dhanalakota
In Gen12 there are various fuse combinations and in each configuration
vdbox engine may be connected to SFC depending on which engines are
available, so we need to set the SFC capability based on fuse value from
the hardware. Even numbered phyical instance
From: Lucas De Marchi
Our _FEATURES macro went back to GEN7, extending each other, making it
difficult to grasp what was really enabled/disabled. Take the
opportunity of the GEN -> XE_HP name break and also break with the
feature inheritance.
For XE_HP this basically goes from GEN12 back to
From: John Harrison
Xe_HP can have a lot of extra media engines. This patch adds the
interrupt handler support for them.
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: John Harrison
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 -
Implement Xe_HP forcewake handling. While we're at it, let's reorder to
the forcewake assignment if/else ladder to match our usual driver
conventions.
Co-authored-by: Daniele Ceraolo Spurio
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
---
Since we can't steer multicast register reads during ring-based
workaround verification, we need to define the multicast ranges where
failure to steer could potentially cause us to read back from a
fused-off register instance.
As with gen12, we can ignore the multicast ranges that the bspec
This series provides some of the initial enablement patches for two
upcoming discrete GPUs:
* XeHP SDV: Xe_HP (version 12.50) graphics IP, no display IP
* DG2: Xe_HPG (version 12.55) graphics IP, Xe_LPD (version 13) display IP
Both platforms will need additional enablement patches beyond
The pull request you sent on Thu, 1 Jul 2021 14:34:15 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-07-01
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e058a84bfddc42ba356a2316f2cf1141974625c9
Thank you!
--
Deet-doot-dot, I am a bot.
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin()
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to
On Wed, Jun 30, 2021 at 9:34 PM Dave Airlie wrote:
>
> Hi Linus,
>
> This is the main drm pull request for 5.14-rc1.
>
> I've done a test pull into your current tree, and hit two conflicts
> (one in vc4, one in amdgpu), both seem pretty trivial, the amdgpu one
> is recent and sfr sent out a
On Thu, Jul 01, 2021 at 11:57:53AM +0300, Jani Nikula wrote:
> On Wed, 30 Jun 2021, Rodrigo Vivi wrote:
> > On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote:
> >> On Tue, 29 Jun 2021, Rodrigo Vivi wrote:
> >> > Hi Dave and Daniel,
> >> >
> >> > Here goes
On Thu, Jul 1, 2021 at 8:27 PM Martin Peres wrote:
>
> On 01/07/2021 11:14, Pekka Paalanen wrote:
> > On Wed, 30 Jun 2021 11:58:25 -0700
> > John Harrison wrote:
> >
> >> On 6/30/2021 01:22, Martin Peres wrote:
> >>> On 24/06/2021 10:05, Matthew Brost wrote:
> From: Daniele Ceraolo Spurio
On 01/07/2021 11:14, Pekka Paalanen wrote:
On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison wrote:
On 6/30/2021 01:22, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
On 30/06/2021 21:00, Matthew Brost wrote:
On Wed, Jun 30, 2021 at 11:22:38AM +0300, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Hi Thomas,
On Thu, Jul 01, 2021 at 02:43:12PM +0200, Thomas Zimmermann wrote:
> Cleanup several nits in the driver's init code. Also move constant
> data into the RO data segment. No functional changes.
>
> Tested on mgag200 HW.
>
> Thomas Zimmermann (4):
> drm/mgag200: Don't pass flags to
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.
v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)
Signed-off-by: Thomas Zimmermann
Fixes: b318b82455bd ("drm/i915: Nuke
Fix a bug in the usage of IRQs and cleanup references to the DRM
IRQ midlayer.
Preferably this patchset would be merged through drm-misc-next.
v5:
* go back to _hardirq() after CI tests reported atomic
context in PCI probe; add rsp comment
v4:
* switch IRQ code to
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
Change all calls to synchronize_hardirq() to intel_synchronize_irq(),
which uses the correct interrupt. _hardirq()
Free transfer and compression buffers on device removal instead of at
DRM device removal time. This ensures that the usual 2x8MB buffers are
released when the device is unplugged and not kept around should
userspace keep the DRM device fd open.
At least Ubuntu 20.04 doesn't release the DRM device
There'a limit to how big a kmalloc buffer can be, and as memory gets
fragmented it becomes more difficult to get big buffers. The downside of
smaller buffers is that the driver has to split the transfer up which
hampers performance. Compression might also take a hit because of the
splitting.
Arm Fixed Rate Compression (AFRC) is a proprietary fixed rate image
compression protocol and format.
It is designed to provide guaranteed bandwidth and memory footprint
reductions in graphics and media use-cases.
This patch aims to add modifier definitions for describing
AFRC.
Signed-off-by:
With the introduction of non-blocking CTBs more than one CTB can be in
flight at a time. Increasing the size of the CTBs should reduce how
often software hits the case where no space is available in the CTB
buffer.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
Add non blocking CTB send function, intel_guc_send_nb. GuC submission
will send CTBs in the critical path and does not need to wait for these
CTBs to complete before moving on, hence the need for this new function.
The non-blocking CTB now must have a flow control mechanism to ensure
the buffer
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely
From: John Harrison
Add several module failure load inject points in the CT buffer creation
code path.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8
1 file changed, 8 insertions(+)
diff
Improve the error message when a unsolicited CT response is received by
printing fence that couldn't be found, the last fence, and all requests
with a response outstanding.
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---
Implement a stall timer which fails H2G CTBs once a period of time
with no forward progress is reached to prevent deadlock.
v2:
(Michal)
- Improve error message in ct_deadlock()
- Set broken when ct_deadlock() returns true
- Return -EPIPE on ct_deadlock()
v3:
(Michal)
- Add ms to stall
As part of enabling GuC submission discussed in [1], [2], and [3] we
need optimize and update the CT code as this is now in the critical
path of submission. This series includes the patches to do that which is
the first 7 patches from [3]. The patches should have addressed all the
feedback in [3]
In upcoming patch we will allow more CTB requests to be sent in
parallel to the GuC for processing, so we shouldn't assume any more
that GuC will always reply without 10ms.
Use bigger value hardcoded value of 1s instead.
v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
v3:
(Daniel Vetter)
drm_file->master pointers should be protected by
drm_device.master_mutex or drm_file.master_lock when being
dereferenced.
However, in drm_lease.c, there are multiple instances where
drm_file->master is accessed and dereferenced while neither lock is
held. This makes drm_lease.c vulnerable to
Currently, drm_file.master pointers should be protected by
drm_device.master_mutex when being dereferenced. This is because
drm_file.master is not invariant for the lifetime of drm_file. If
drm_file is not the creator of master, then drm_file.is_master is
false, and a call to drm_setmaster_ioctl
While checking the master status of the DRM file in
drm_is_current_master(), the device's master mutex should be
held. Without the mutex, the pointer fpriv->master may be freed
concurrently by another process calling drm_setmaster_ioctl(). This
could lead to use-after-free errors when the pointer
In a future patch, _drm_lease_held will dereference drm_file->master
only after making a call to drm_file_get_master. This will increment
the reference count of drm_file->master while holding onto a new
drm_file.master_lock.
In preparation for this, the call to _drm_lease_held should be moved
out
In preparation for a future patch to take a lock on
drm_device.master_mutex inside drm_is_current_master(), we first move
the call to drm_is_current_master() in drm_mode_getconnector out from the
section locked by >mode_config.mutex. This avoids creating a
circular lock dependency.
Failing to
1 - 100 of 153 matches
Mail list logo
