On Wed, 2021-09-01 at 19:17 -0700, Randy Dunlap wrote:
> Fix a build error on CONFIG_UML, which does not support (provide)
> wbinvd(). UML can use the generic mb() instead.
>
> ../drivers/gpu/drm/r128/ati_pcigart.c: In function ‘drm_ati_pcigart_init’:
> ../drivers/gpu/drm/r128/ati_pcigart.c:218:2:
On 02/09/2021 06:52, Randy Dunlap wrote:
On 9/1/21 10:48 PM, Anton Ivanov wrote:
On 02/09/2021 03:01, Randy Dunlap wrote:
boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
member named 'x86', so provide a default page protection mode
for CONFIG_UML.
Mends this build error:
../d
On 02/09/2021 03:01, Randy Dunlap wrote:
boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
member named 'x86', so provide a default page protection mode
for CONFIG_UML.
Mends this build error:
../drivers/gpu/drm/ttm/ttm_module.c: In function ‘ttm_prot_from_caching’:
../drivers/gp
Il 30/08/21 20:24, Marijn Suijten ha scritto:
All DSI PHY/PLL drivers were referencing their VCO parent clock by a
global name, most of which don't exist or have been renamed. These
clock drivers seem to function fine without that except the 14nm driver
for the sdm6xx [1].
At the same time all
Il 30/08/21 20:24, Marijn Suijten ha scritto:
The DSI PHY/PLL was relying on a global "xo" clock to be found, but the
real clock is named "xo_board" in the DT. The standard nowadays is to
never use global clock names anymore but require the firmware (DT) to
provide every clock binding explicitly
On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
> > >
> > > I have a question though - why all of DRM is not !UML in config. Not
> > > like we can use them.
> >
> > I have no idea about that.
> > Hopefully one of the (other) UML maintainers can answer you.
>
> Touche.
>
> We will discus
https://bugzilla.kernel.org/show_bug.cgi?id=212655
coxackie (kostas.karda...@gmail.com) changed:
What|Removed |Added
CC||kostas.karda...@gma
On Thu, 2021-09-02 at 09:10 +0100, Anton Ivanov wrote:
> On 02/09/2021 08:43, Johannes Berg wrote:
> > On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
> > > > >
> > > > > I have a question though - why all of DRM is not !UML in config. Not
> > > > > like we can use them.
> > > >
> > > > I
Am 02.09.21 um 09:43 schrieb Johannes Berg:
On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
I have a question though - why all of DRM is not !UML in config. Not
like we can use them.
I have no idea about that.
Hopefully one of the (other) UML maintainers can answer you.
Touche.
We will
Hi All,
Our last night's test on rpi4 had a nasty trace. The test was with
7c636d4d20f8 ("Merge tag 'dt-5.15' of
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc"). Previous test
was on 9e9fb7655ed5 ("Merge tag 'net-next-5.15' of
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next")
On 31/08/2021 08:53, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: Steven Price
I'll push this to drm-misc-next.
Thanks,
Steve
> ---
> dr
This can be used to create a separate DRM file description, thus
creating a new GEM handle namespace. See [1].
Example usage in wlroots is available at [2].
[1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
[2]: https://github.com/swaywm/wlroots/pull/3158
Signed-off-by: Simon Ser
On 01/09/2021 19:54, Alyssa Rosenzweig wrote:
> Replace our open-coded FRAC_16_16 with the common drm_fixed_16_16
> helper to reduce code duplication between drivers.
>
> Signed-off-by: Alyssa Rosenzweig
> Cc: linux-amlo...@lists.infradead.org
> ---
> drivers/gpu/drm/meson/meson_overlay.c | 7 ++
On 02/09/2021 08:43, Johannes Berg wrote:
On Thu, 2021-09-02 at 07:19 +0100, Anton Ivanov wrote:
I have a question though - why all of DRM is not !UML in config. Not
like we can use them.
I have no idea about that.
Hopefully one of the (other) UML maintainers can answer you.
Touche.
We wil
Op 31-08-2021 om 17:14 schreef Daniel Vetter:
> On Tue, Aug 31, 2021 at 02:16:56PM +0200, Daniel Vetter wrote:
>> On Tue, Aug 31, 2021 at 11:38:27AM +0200, Maarten Lankhorst wrote:
>>> Op 14-08-2021 om 12:43 schreef Daniel Vetter:
The only reason for this really is the i915_gem_engines->fence
Hi Monk,
Am 02.09.21 um 07:52 schrieb Liu, Monk:
[AMD Official Use Only]
I'm not sure I can add much to help this along, I'm sure Alex has some internal
training,
Once your driver is upstream, it belongs to upstream, you can maintain it, but
you no longer control it 100%, it's a tradeoff, it'
Am 01.09.21 um 16:53 schrieb Sumit Semwal:
Hi Christian,
On Wed, 1 Sept 2021 at 13:30, Christian König
wrote:
The seqno-fence was removed, cleanup the kerneldoc include as well.
Signed-off-by: Christian König
Fixes: 992c238188a8 ("dma-buf: nuke seqno-fence")
Thanks for fixing; LGTM, please
Implement backup and restore of LMEM during suspend / resume.
What complicates things a bit is handling of pinned LMEM memory during
suspend and the fact that we might be dealing with unmappable LMEM in
the future, which makes us want to restrict the number of pinned objects that
need memcpy resume
When backing up or restoring contents of pinned objects at suspend /
resume time we need to allocate a new object as the backup. Add a function
to facilitate copies between the two. Some data needs to be copied before
the migration context is ready for operation, so make sure we can
disable acceler
An upcoming common pattern is to traverse the region object list and
perform certain actions on all objects in a region. It's a little tricky
to get the list locking right, in particular since a gem object may
change region unless it's pinned or the object lock is held.
Define a function that does
Just evict unpinned objects to system. For pinned LMEM objects,
make a backup system object and blit the contents to that.
For now, for pinned objects, backup using gpu blits and restore using
memcpy except for occasional user-space objects which are restored
using gpu blits once the migration con
Pinned contexts, like the migrate contexts need reset after resume
since their context image may have been lost. Also the GuC needs to
register pinned contexts.
Add a list to struct intel_engine_cs where we add all pinned contexts on
creation, and traverse that list at resume time to reset the pin
Pinned context images are now reset during resume. Don't back them up,
and assuming that rings can be assumed empty at suspend, don't back them
up either.
Introduce a new object flag, I915_BO_ALLOC_PM_VOLATILE meaning that an
object is allowed to lose its content on suspend.
Signed-off-by: Thomas
We really only need memcpy restore for objects that affect the
operability of the migrate context. That is, primarily the page-table
objects of the migrate VM.
Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early
restores using memcpy and a way to assign LMEM page-table object fl
On 9/1/21 5:24 PM, Simon Ser wrote:
Ideally the final composition format would have enough precision for
all of the planes. I think it'd make sense to use ARGB16161616 if the
primary plane uses ARGB and an overlay plane uses ARGB16161616.
To simplify the code, maybe it's fine to always use A
On Wed, 01 Sep 2021 16:32:13 +0800, Yunfei Dong wrote:
> Adds decoder dt-bindings for mt8192.
>
> Signed-off-by: Yunfei Dong
> ---
> v6: add decoder block diagram for Laurent's comments.
>
> This patch depends on "Mediatek MT8192 clock support"[1].
>
> The definition of decoder clocks are in mt
On 13/08/2021 21:30, Daniel Vetter wrote:
The only reason for this really is the i915_gem_engines->fence
callback engines_notify(), which exists purely as a fairly funky
reference counting scheme for that. Otherwise all other callers are
from process context, and generally fairly benign locking
On Tue, Aug 31, 2021 at 07:21:06PM +0800, Christian König wrote:
> Move that function into the resource handling and remove an unused parameter.
>
> Signed-off-by: Christian König
Looks this patch is separate from others in this series.
new_flags won't be used anymore.
Reviewed-by: Huang Rui
DMA-BUF sysfs statistics are an option of DMA-BUF. It does not make
much sense to bother the user with a question about DMA-BUF sysfs
statistics if DMA-BUF itself is not enabled. Worse, enabling the
statistics enables the feature.
Fixes: bdb8d06dfefd666d ("dmabuf: Add the capability to expose DM
Move notify between drivers is an option of DMA-BUF. Enabling
DMABUF_MOVE_NOTIFY without DMA_SHARED_BUFFER does not have any impact,
as drivers/dma-buf/ is not entered during the build when
DMA_SHARED_BUFFER is disabled.
Fixes: bb42df4662a44765 ("dma-buf: add dynamic DMA-buf handling v15")
Signed
DMA-BUF debug checks are an option of DMA-BUF. Enabling DMABUF_DEBUG
without DMA_SHARED_BUFFER does not have any impact, as drivers/dma-buf/
is not entered during the build when DMA_SHARED_BUFFER is disabled.
Fixes: 84335675f2223cbd ("dma-buf: Add debug option")
Signed-off-by: Geert Uytterhoeven
Hi Sumit, Christian,
This patch series adds missing dependencies on DMA_SHARED_BUFFER to
various options of DMA-BUF, and drops a bogus select.
As drivers/dma-buf/Kconfig contains interleaved options that select or
depend on DMA_SHARED_BUFFER, they can't be wrapped inside a big
"if DMA_SHA
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #42 from James Zhu (jam...@amd.com) ---
Hi Jerome and kolAflash,
Thanks for confirmation. I have a workaround for this issue. But I wish I can
find the root cause or better workaround.
James
--
You may reply to this email to add a
On 2021-09-01 20:46:34, Stephen Boyd wrote:
> Quoting Marijn Suijten (2021-09-01 01:57:15)
> > On 2021-08-31 22:35:56, Stephen Boyd wrote:
> > > Quoting Marijn Suijten (2021-08-30 11:24:45)
> > > > The DSI PHY/PLL was relying on a global "xo" clock to be found, but the
> > > > real clock is named "
Hi Dongliang,
On Thu, Sep 2, 2021 at 8:04 AM Dongliang Mu wrote:
> [ Upstream commit a49145acfb975d921464b84fe00279f99827d816 ]
Oops, looks like I missed when that one was submitted for review...
> A fb_ioctl() FBIOPUT_VSCREENINFO call with invalid xres setting
> or yres setting in struct fb_va
On Tue, Aug 31, 2021 at 07:21:07PM +0800, Christian König wrote:
> More flexible than the busy placements.
>
> Signed-off-by: Christian König
Patch 2 -> 5 are Acked-by: Huang Rui
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 8 +++-
> include/drm/ttm/ttm_placement.h | 6 ++
> 2 files chan
On Thu, Sep 2, 2021 at 1:52 AM Liu, Monk wrote:
>
> [AMD Official Use Only]
>
> >>>
> I'm not sure I can add much to help this along, I'm sure Alex has some
> internal training,
> Once your driver is upstream, it belongs to upstream, you can maintain it,
> but you no longer control it 100%, it's
It turns out that when locking a region, the region must be a naturally
aligned power of 2. The upshot of this is that if the desired region
crosses a 'large boundary' the region size must be increased
significantly to ensure that the locked region completely covers the
desired region. Previous cal
Den 31.08.2021 14.23, skrev Daniel Vetter:
> On Mon, Aug 30, 2021 at 02:08:14PM +0200, Noralf Trønnes wrote:
>>
>>
>> Den 17.08.2021 15.56, skrev Daniel Vetter:
>>> On Tue, Aug 17, 2021 at 02:29:12PM +0200, Noralf Trønnes wrote:
Add XRGB emulation support for devices that can only do RG
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #43 from kolAflash (kolafl...@kolahilft.de) ---
(In reply to James Zhu from comment #42)
> Hi Jerome and kolAflash,
>
> Thanks for confirmation. I have a workaround for this issue. But I wish I
> can find the root cause or better work
The only reason for this really is the i915_gem_engines->fence
callback engines_notify(), which exists purely as a fairly funky
reference counting scheme for that. Otherwise all other callers are
from process context, and generally fairly benign locking context.
Unfortunately untangling that requi
gem context refcounting is another exercise in least locking design it
seems, where most things get destroyed upon context closure (which can
race with anything really). Only the actual memory allocation and the
locks survive while holding a reference.
This tripped up Jason when reimplementing the
The comment added in
commit b81dde719439c8f09bb61e742ed95bfc4b33946b
Author: Chris Wilson
Date: Tue May 21 22:11:29 2019 +0100
drm/i915: Allow userspace to clone contexts on creation
and moved in
commit 27dbae8f36c1c25008b7885fc07c57054b7dfba3
Author: Chris Wilson
The important part isn't so much that this does an rcu lookup - that's
more an implementation detail, which will also be removed.
The thing that makes this different from other functions is that it's
gettting you the vm that batchbuffers will run in for that gem
context, which is either a full ppg
Changing the vm from a finalized gem ctx is no longer possible, which
means we don't have to check for that anymore.
I was pondering whether to keep the check as a WARN_ON, but things go
boom real bad real fast if the vm of a vma is wrong. Plus we'd need to
also get the ggtt vm for !full-ppgtt pla
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks it's really only set
when we have full ppgtt, just in case. gem_context->vm is different
since it's NULL in ggtt mode, unlike intel_context->vm or gt->vm,
Since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
the gem_ctx->vm can't change anymore. Plus we always set the
intel_context->vm, so might as well use the help
Consolidates the "which is the vm my execbuf runs in" code a bit. We
do some get/put which isn't really required, but all the other users
want the refcounting, and I figured doing a function just for this
getparam to avoid 2 atomis is a bit much.
Reviewed-by: Maarten Lankhorst
Signed-off-by: Dani
It's been invariant since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
this just completes the deed. I've tried to split out prep work for
more
The full audit is quite a bit of work:
- i915_dpt has very simple lifetime (somehow we create a display pagetable vm
per object, so its _very_ simple, there's only ever a single vma in there),
and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu.
Aside: wtf is i915_dpt do
We don't need the absolute speed of rcu for this. And
i915_address_space in general dont need rcu protection anywhere else,
after we've made gem contexts and engines a lot more immutable.
Note that this semantically reverts
commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
Author: Chris Wilson
Dat
On Thu, Sep 02, 2021 at 04:08:14PM +0200, Noralf Trønnes wrote:
>
>
> Den 31.08.2021 14.23, skrev Daniel Vetter:
> > On Mon, Aug 30, 2021 at 02:08:14PM +0200, Noralf Trønnes wrote:
> >>
> >>
> >> Den 17.08.2021 15.56, skrev Daniel Vetter:
> >>> On Tue, Aug 17, 2021 at 02:29:12PM +0200, Noralf Trø
On Tue, Aug 31, 2021 at 02:24:52PM -0400, Andrey Grodzovsky wrote:
>
> On 2021-08-31 9:11 a.m., Daniel Vetter wrote:
> > On Thu, Aug 26, 2021 at 11:04:14AM +0200, Daniel Vetter wrote:
> > > On Thu, Aug 19, 2021 at 11:25:09AM -0400, Andrey Grodzovsky wrote:
> > > > On 2021-08-19 5:30 a.m., Daniel V
On Thu, 02 Sep 2021 09:11:40 +
Simon Ser wrote:
> This can be used to create a separate DRM file description, thus
> creating a new GEM handle namespace. See [1].
>
> Example usage in wlroots is available at [2].
>
> [1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
> [2]: h
On Wed, Sep 01, 2021 at 11:08:10AM +0200, Javier Martinez Canillas wrote:
> On 8/31/21 2:35 PM, Daniel Vetter wrote:
> > On Sat, Aug 28, 2021 at 12:02:21AM +0200, Javier Martinez Canillas wrote:
>
> [snip]
>
> >>
> >> We talked about a drmcon with Peter Robinson as well but then decided that
> >
On Tue, Aug 31, 2021 at 02:18:15PM +0100, Tvrtko Ursulin wrote:
>
> On 31/08/2021 13:43, Daniel Vetter wrote:
> > On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 30/08/2021 09:26, Daniel Vetter wrote:
> > > > On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin
On Wed, Sep 01, 2021 at 02:02:39PM +0200, Christian König wrote:
> This callback is pretty much deprecated and should not be used by new
> implementations.
>
> Clarify that in the documentation as well.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> include/linux/dma
On Wed, Sep 01, 2021 at 02:02:40PM +0200, Christian König wrote:
> That the caller doesn't need to keep a reference is rather
> risky and not defensive at all.
>
> Especially dma_buf_poll got that horrible wrong, so better
> remove that sentence and also clarify that the callback
> might be called
On Thu, Sep 02, 2021 at 07:19:01AM +0100, Anton Ivanov wrote:
> On 02/09/2021 06:52, Randy Dunlap wrote:
> > On 9/1/21 10:48 PM, Anton Ivanov wrote:
> > > On 02/09/2021 03:01, Randy Dunlap wrote:
> > > > boot_cpu_data [struct cpuinfo_um (on UML)] does not have a struct
> > > > member named 'x86', s
On Thu, Sep 02, 2021 at 05:28:10PM +0300, Pekka Paalanen wrote:
> On Thu, 02 Sep 2021 09:11:40 +
> Simon Ser wrote:
>
> > This can be used to create a separate DRM file description, thus
> > creating a new GEM handle namespace. See [1].
> >
> > Example usage in wlroots is available at [2].
>
On 02/09/2021 15:20, Daniel Vetter wrote:
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks it's really only set
when we have full ppgtt, just in case. gem_context->vm is different
since it's NULL in
https://bugzilla.kernel.org/show_bug.cgi?id=214289
Bug ID: 214289
Summary: amdgpu Msg issuing pre-check failed and SMU may be not
in the right state!
Product: Drivers
Version: 2.5
Kernel Version: 5.13.13
Hardware: Intel
On 02/09/2021 15:33, Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 02:18:15PM +0100, Tvrtko Ursulin wrote:
On 31/08/2021 13:43, Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 10:15:03AM +0100, Tvrtko Ursulin wrote:
On 30/08/2021 09:26, Daniel Vetter wrote:
On Fri, Aug 27, 2021 at 03:44:42PM
This patch adds a 60 fps mode to the Orisetech OTM8009A panel.
The 50 fps mode is left as preferred.
Signed-off-by: Raphael Gallais-Pou
---
.../gpu/drm/panel/panel-orisetech-otm8009a.c | 85 ---
1 file changed, 56 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/pane
On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
wrote:
>
>
> On 13/08/2021 21:30, Daniel Vetter wrote:
> > The only reason for this really is the i915_gem_engines->fence
> > callback engines_notify(), which exists purely as a fairly funky
> > reference counting scheme for that. Otherwise all other c
On Thu, Sep 02, 2021 at 03:54:36PM +0100, Tvrtko Ursulin wrote:
> On 02/09/2021 15:20, Daniel Vetter wrote:
> > And use it anywhere we have open-coded checks for ctx->vm that really
> > only check for full ppgtt.
> >
> > Plus for paranoia add a GEM_BUG_ON that checks it's really only set
> > when
Defines plane ordering by hard-coding an immutable Z position from the
first plane, used as primary layer, to the next ones as overlay in order
of instantiation.
This zpos is only an information as it is not possible to modify it,
blending operations are still applied from the top to the bottom la
On 2021-09-02 10:28 a.m., Daniel Vetter wrote:
On Tue, Aug 31, 2021 at 02:24:52PM -0400, Andrey Grodzovsky wrote:
On 2021-08-31 9:11 a.m., Daniel Vetter wrote:
On Thu, Aug 26, 2021 at 11:04:14AM +0200, Daniel Vetter wrote:
On Thu, Aug 19, 2021 at 11:25:09AM -0400, Andrey Grodzovsky wrote:
O
https://bugzilla.kernel.org/show_bug.cgi?id=214289
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Thu, Sep 2, 2021 at 1:00 PM Christian König wrote:
>
> Hi Monk,
>
> Am 02.09.21 um 07:52 schrieb Liu, Monk:
> > [AMD Official Use Only]
> >
> > I'm not sure I can add much to help this along, I'm sure Alex has some
> > internal training,
> > Once your driver is upstream, it belongs to upstream
On 02/09/2021 16:05, Daniel Vetter wrote:
On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
wrote:
On 13/08/2021 21:30, Daniel Vetter wrote:
The only reason for this really is the i915_gem_engines->fence
callback engines_notify(), which exists purely as a fairly funky
reference counting scheme
From: Vladimir Lypak
MDP version v1.16 is almost identical to v1.15 with most significant
difference being presence of second DSI interface. MDP v1.16 is found on
SoCs such as MSM8x53, SDM450, SDM632 (All with Adreno 506).
Signed-off-by: Vladimir Lypak
Signed-off-by: Sireesh Kodali
---
driver
From: Vladimir Lypak
Add phy configuration for 14nm dsi phy found on MSM8953 SoC. Only
difference from existing configurations are io_start addresses.
Signed-off-by: Vladimir Lypak
Signed-off-by: Sireesh Kodali
---
.../bindings/display/msm/dsi-phy-14nm.yaml| 1 +
drivers/gpu/drm/msm/dsi/
This patch series adds support for the MDP and DSI PHY as found on the
MSM8953 platform (APQ8053, SDM450, SDA450, SDM625, SDM626). All the SoCs
on this platform use the adreno 506 GPU.
Vladimir Lypak (2):
drm/msm/dsi: Add phy configuration for MSM8953
drm/msm/mdp5: Add configuration for MDP v1
On Wed, 1 Sept 2021 at 05:32, Yunfei Dong wrote:
>
> This series adds support for multi hardware decode into mtk-vcodec, by first
> adding component framework to manage each hardware information: interrupt,
> clock, register bases and power. Secondly add core thread to deal with core
> hardware me
https://bugzilla.kernel.org/show_bug.cgi?id=214289
--- Comment #2 from Michal Przybylowicz (michal.przybylow...@gmail.com) ---
Created attachment 298645
--> https://bugzilla.kernel.org/attachment.cgi?id=298645&action=edit
dmesg
full dmesg extraced using:
$ journalctl -k -b -1 --no-pager > ~/Do
https://bugzilla.kernel.org/show_bug.cgi?id=214289
--- Comment #3 from Michal Przybylowicz (michal.przybylow...@gmail.com) ---
Just one thing that I have noticed it looks like these messages appear when I
do some interactions on webpages like clicking dropdown...
I am using Vivaldi: 4.1.2369.21
On 02/09/2021 16:22, Daniel Vetter wrote:
On Thu, Sep 02, 2021 at 03:54:36PM +0100, Tvrtko Ursulin wrote:
On 02/09/2021 15:20, Daniel Vetter wrote:
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks
Hi Monk,
On Thu, 2 Sept 2021 at 06:52, Liu, Monk wrote:
> I didn't mean your changes on AMD driver need my personal approval or review
> ... and I'm totally already get used that our driver is not 100% under
> control by AMDers,
> but supposedly any one from community (including you) who tend
On 9/1/2021 17:50, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DOC
v3:
- Fixup a few kernel doc comments (Dani
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Thursday, September 2, 2021 9:42 AM
> To: Daniel Vetter
> Cc: Daniel Vetter ; DRI Development de...@lists.freedesktop.org>; Intel Graphics Development g...@lists.freedesktop.org>; Maarten Lankhorst
> ; Vetter, Daniel
> ; Bloomfield, Jo
On 9/2/2021 10:01 AM, John Harrison wrote:
On 9/1/2021 17:50, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DO
On Thu, Sep 2, 2021 at 1:18 AM Christoph Hellwig wrote:
>
> On Wed, Sep 01, 2021 at 11:40:43AM -0400, Felix Kuehling wrote:
> > >>> It looks like I'm totally misunderstanding what you are adding here
> > >>> then. Why do we need any special treatment at all for memory that
> > >>> has normal stru
Reviewed-by: Lyude Paul
Do you need me to push this?
On Tue, 2021-08-31 at 04:51 -0700, cgel@gmail.com wrote:
> From: Chi Minghao
>
> Fix the following coccicheck REVIEW:
> ./drivers/gpu/drm/msm/edp/edp_ctrl.c:1245:5-8 Unneeded variable
>
> Reported-by: Zeal Robot
> Signed-off-by: Chi Mi
On 9/1/2021 17:50, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
When the GuC does a media reset, it copies a golden context state back
into the corrupted context's state. The address of the golden context
and the size of the engine state restore are passed in via the GuC ADS.
The i915 had
Quoting Marijn Suijten (2021-09-02 06:05:34)
> On 2021-09-01 20:46:34, Stephen Boyd wrote:
> > Quoting Marijn Suijten (2021-09-01 01:57:15)
> > > On 2021-08-31 22:35:56, Stephen Boyd wrote:
> > > > Quoting Marijn Suijten (2021-08-30 11:24:45)
> > > > > The DSI PHY/PLL was relying on a global "xo" c
On Thu, Sep 02, 2021 at 05:05:05PM +, Bloomfield, Jon wrote:
> > -Original Message-
> > From: Tvrtko Ursulin
> > Sent: Thursday, September 2, 2021 9:42 AM
> > To: Daniel Vetter
> > Cc: Daniel Vetter ; DRI Development > de...@lists.freedesktop.org>; Intel Graphics Development > g...@
On Thu, Sep 2, 2021 at 6:20 PM Tvrtko Ursulin
wrote:
> On 02/09/2021 16:05, Daniel Vetter wrote:
> > On Thu, Sep 2, 2021 at 2:42 PM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 13/08/2021 21:30, Daniel Vetter wrote:
> >>> The only reason for this really is the i915_gem_engines->fence
> >>> callbac
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #44 from James Zhu (jam...@amd.com) ---
Created attachment 298651
--> https://bugzilla.kernel.org/attachment.cgi?id=298651&action=edit
A workaround for suspend/resume hung issue
The VCN block passed all ring tests, usually the vcn w
From: Colin Ian King
There are a couple of statements that are indented one character
too deeply, clean these up.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdg
From: Colin Ian King
There is a statement that is indented incorrectly. Clean it up.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
b/drivers/gpu/drm/am
From: Colin Ian King
There is a statement that is indented one character too deeply,
clean this up.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists
Removed most CC: SMTP server protested.
On 01.09.2021 22:19, Douglas Anderson wrote:
> 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
On 9/1/2021 17:49, Daniele Ceraolo Spurio wrote:
From: Matthew Brost
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This wa
On 02/09/2021 18:59, Sireesh Kodali wrote:
From: Vladimir Lypak
Add phy configuration for 14nm dsi phy found on MSM8953 SoC. Only
difference from existing configurations are io_start addresses.
Signed-off-by: Vladimir Lypak
Signed-off-by: Sireesh Kodali
---
.../bindings/display/msm/dsi-phy
On 01/09/2021 21:11, AngeloGioacchino Del Regno wrote:
The enum dpu_clk_ctrl_type misses DPU_CLK_CTRL_DMA{2,3} even though
this driver does actually handle both, if present: add the two in
preparation for adding support for SoCs having them.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed
On 01/09/2021 21:11, AngeloGioacchino Del Regno wrote:
Bringup functionality for MSM8998 in the DPU, driver which is mostly
the same as SDM845 (just a few variations).
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
Hi,
On Thu, Sep 2, 2021 at 3:10 PM Andrzej Hajda wrote:
>
> Removed most CC: SMTP server protested.
Yeah, it was because of the dang defconfig patches. My general policy
is to send the cover letter to everyone even if not everyone gets CCed
on all patches, but it ended up as a lot... Speaking of
From: John Harrison
Various UMDs require hardware configuration information about the
current platform. A bunch of static information is available in a
fixed table that can be retrieved from the GuC.
Test-with: 20210727002812.43469-2-john.c.harri...@intel.com
UMD: https://github.com/intel/comput
From: Rodrigo Vivi
GuC contains a consolidated table with a bunch of information about the
current device.
Previously, this information was spread and hardcoded to all the components
including GuC, i915 and various UMDs. The goal here is to consolidate
the data into GuC in a way that all interes
1 - 100 of 110 matches
Mail list logo
