On Thu, Sep 09, 2021 at 03:16:22PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > For testing purposes it may make sense to reduce the number of guc_ids
> > available to be allocated. Add debugfs support for setting the number of
> > guc_ids.
> >
> > Signed-off-by: Matt
On Thu, Sep 09, 2021 at 03:28:51PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > circuiting while a deregister context H2G is in flight.
> >
> > FIXME: Move locking / structure changes into differen
On Thu, Sep 09, 2021 at 03:36:44PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Sometimes it is desirable to queue work up for later if the GT PM isn't
> > held and run that work on next GT PM unpark.
> What is the reason for doing this? Why is it important? Why not ju
On Thu, Sep 09, 2021 at 03:46:43PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > circuiting while a scheduling of user context could be enabled.
> As with earlier PM patch, needs more explanation of
Hi all,
On Thu, 2 Sep 2021 11:22:08 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the amdgpu tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
>
> between commit:
>
> 477f70cd2a67 ("Merge tag 'drm-next-2021-08-31-1' of
> git://anongit.freedesktop.
Current (and older) Simics models for the Bochs VGA used the wrong PCI
vendor ID (0x4321 instead of 0x1234). Although this can hopefully be
fixed in the future, it is a problem for users of the current version,
not the least because to update the device ID the BIOS has to be
rebuilt in order to se
Vendor will define their own memory types on top of TTM_PL_PRIV,
but call ttm_set_driver_manager directly without checking mem_type
value when setting up memory manager. So add such check to aware
the case when array bounds.
Signed-off-by: Leslie Shi
Signed-off-by: Guchun Chen
---
include/drm/t
[AMD Official Use Only]
looks good to me.
But maybe build_bug_on works too and more reasonable to detect such wrong usage.
From: Chen, Guchun
Sent: Friday, September 10, 2021 12:30:14 PM
To: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ; Koenig
On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we
simply check whether the register offset is < 0x4, and return
FORCEWAKE_RENDER if it is. To prepare for upcoming refactoring, let's
define a single-entry forcewake table from [0x0, 0x3] and switch
these platforms over
Our uncore MMIO functions for reading/writing registers have become very
complicated over time. There's significant macro magic used to generate
several nearly-identical functions that only really differ in terms of
which platform-specific shadow register table they should check on write
operation
We thought the DG2 table of shadowed registers would be the same as the
gen12/xehp table, but it turns out that there are a few minor
differences that require us to define a new DG2-specific table:
* One register is removed (0xC4D4)
* One register is added (0xC4E0)
Signed-off-by: Matt Roper
---
Now that the reference to the shadow table is stored within the uncore,
we don't need to generate separate fwtable, gen11_fwtable, and
gen12_fwtable variants of the register write functions; a single
'fwtable' implementation will work for all of those platforms now.
Note that while consolidating d
Now that we have both a standard forcewake table (albeit a single-entry
table) and the shadow table stored in the uncore, we can drop the
gen8-specific write handlers in favor of the general fwtable version.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_uncore.c | 13 +
1
Store a reference to a platform's shadow table inside the uncore, the
same as we do with the forcewake table. This will allow us to use a
single set of functions that operate on the shadow table reference
rather than generating lots of nearly-identical functions via macros
that differ only in term
Consolidate down to just a single 'fwtable' implementation. For reads
we don't need to worry about shadow tables. Also, the
NEEDS_FORCE_WAKE() check we previously had in the fwtable implementation
can be dropped --- if a register is outside that range on one of the old
platforms, then it won't be
Hi Chun-Kuang,
On Fri, Sep 10, 2021 at 07:37:50AM +0800, Chun-Kuang Hu wrote:
> Hi, Markus:
>
> Markus Schneider-Pargmann 於 2021年9月7日 週二 上午3:37寫道：
> >
> > This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
> >
> > It supports both functional units on the mt8195, the embedded
> > D
On Thu, 9 Sept 2021 at 19:30, Daniel Vetter wrote:
>
> On Thu, Sep 9, 2021 at 5:35 AM Dave Airlie wrote:
> >
> > On Thu, 9 Sept 2021 at 03:44, Thomas Zimmermann wrote:
> > >
> > > Hi Dave and Daniel,
> > >
> > > here's this week's PR for drm-misc-fixes. One patch is a potential
> > > deadlock
>
Hi Linus,
Just an initial bunch of fixes for the merge window, amdgpu is most of
them with a few ttm fixes and an fbdev avoid multiply overflow fix.
Dave.
drm-next-2021-09-10:
drm fixes for 5.15-rc1
ttm:
- Fix ttm_bo_move_memcpy() when ttm_resource is subclassed.
- Fix ttm deadlock if target BO
Yeah, that's a good point.
If build_bug_on() doesn't works for some reason then we at least need to
lower this to a WARN_ON.
A BUG_ON() is only justified if we prevent strong data corruption with
it or note a NULL pointer earlier on or similar.
Regards,
Christian.
Am 10.09.21 um 06:36 schr
301 - 319 of 319 matches
Mail list logo
