From: Søren Andersen
Add support for the LOGIC Technologies, Inc LTTD800480070-L6WH-RT
Co-Developed-by: Søren Andersen
Co-Developed-by: Sam Ravnborg
Signed-off-by: Søren Andersen
Signed-off-by: Sam Ravnborg
Signed-off-by: Oleksij Rempel
---
drivers/gpu/drm/panel/panel-simple.c | 34
From: Sam Ravnborg
The Multi Innotechnology is a 10.1" 1280x800 panel.
The datasheet did not specify specific values for sync, back, front porch.
The values are a best guess based on values for similar panels.
Co-Developed-by: Sam Ravnborg
Co-Developed-by: Ulrich Ölmann
Signed-off-by: Sam
Applied. Thanks!
Alex
On Wed, Aug 4, 2021 at 2:49 AM Christian König wrote:
>
> Am 04.08.21 um 03:51 schrieb Tuo Li:
> > The varialbe gtt in the function amdgpu_ttm_tt_populate() and
> > amdgpu_ttm_tt_unpopulate() is guaranteed to be not NULL in the context.
> > Thus the null-pointer checks
On Tue, Aug 3, 2021 at 10:39 PM Zhenneng Li wrote:
>
>
> When primary bo is updated, crtc's pitch may
> have not been updated, this will lead to show
> disorder content when user changes display mode,
> we update crtc's pitch in page flip to avoid
> this bug.
> This refers to amdgpu's pageflip.
>
Hi Daniel,
> > >>> The solution:
> > >>> - To ensure full framerate, the Guest compositor has to start it's
> > >>> repaint cycle
> (including
> > >>> the 9 ms wait) when the Host compositor sends the frame callback event
> > >>> to its
> clients.
> > >>> In order for this to happen, the
Hi Dave, Daniel,
Fixes for 5.14.
The following changes since commit d28e2568ac26fff351c846bf74ba6ca5dded733e:
Merge tag 'amd-drm-fixes-5.14-2021-07-28' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2021-07-29 17:20:29
+1000)
are available in the Git repository at:
On Tue, Aug 03, 2021 at 10:47:10AM -0500, Jason Ekstrand wrote:
> Both are
>
> Reviewed-by: Jason Ekstrand
CI is happy, I guess you got all the igt changes indeed. Both pushed
thanks for reviewing.
-Daniel
>
> On Tue, Aug 3, 2021 at 7:49 AM Daniel Vetter wrote:
> >
> > It's already removed,
On Mon, Aug 02, 2021 at 04:35:51PM +0300, Imre Deak wrote:
> Atm the EFI FB driver gets a runtime PM reference for the associated GFX
> PCI device during driver probing and releases it only when removing the
> driver.
>
> When fbcon switches to the FB provided by the PCI device's driver (for
>
On Wed, Aug 4, 2021 at 11:10 PM Arnd Bergmann wrote:
>
> On Wed, Aug 4, 2021 at 8:59 PM Karol Herbst wrote:
> > On Wed, Aug 4, 2021 at 4:43 PM Karol Herbst wrote:
> > > On Wed, Aug 4, 2021 at 4:19 PM Arnd Bergmann wrote:
> > > > On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
> > > > >
> >
On Wed, 4 Aug 2021 at 19:57, Jason Ekstrand wrote:
> While tracking down various bits of i915 uAPI, it's been difficult to
> find the userspace much of the time because no one bothers to mention it
> in commit messages. Require the kernel patch to be a one-stop shop for
> finding the various
Hi Chenyang,
some feedback in the following.
I will try to find more time for review during the week.
Hi Thomas,
please see my question near drm_gem_vram_of_gem().
Sam
On Fri, Jul 30, 2021 at 05:41:46PM +0800, lichenyang wrote:
> From: Chenyang Li
>
> This patch adds an initial DRM
On Wed, Aug 4, 2021 at 8:59 PM Karol Herbst wrote:
> On Wed, Aug 4, 2021 at 4:43 PM Karol Herbst wrote:
> > On Wed, Aug 4, 2021 at 4:19 PM Arnd Bergmann wrote:
> > > On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
> > > >
> > > > playing around a little bit with this, I think the original
On Wed, Aug 4, 2021 at 3:41 PM Randy Dunlap wrote:
>
> Fix modpost Section mismatch error in i915_globals_exit().
> Since both an __init function and an __exit function can call
> i915_globals_exit(), any function that i915_globals_exit() calls
> should not be marked as __init or __exit. I.e., it
Fix modpost Section mismatch error in i915_globals_exit().
Since both an __init function and an __exit function can call
i915_globals_exit(), any function that i915_globals_exit() calls
should not be marked as __init or __exit. I.e., it needs to be
available for either of them.
WARNING: modpost:
On Mon, Aug 02, 2021 at 10:11:18PM -0700, Matthew Brost wrote:
> From: Venkata Sandeep Dhanalakota
>
> Defining vma on stack can cause stack overflow, if
> vma gets populated with new fields.
>
> Cc: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
> Signed-off-by: Venkata Sandeep Dhanalakota
>
On Wed, Aug 4, 2021 at 4:43 PM Karol Herbst wrote:
>
> On Wed, Aug 4, 2021 at 4:19 PM Arnd Bergmann wrote:
> >
> > On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
> > >
> > > playing around a little bit with this, I think the original "select
> > > BACKLIGHT_CLASS_DEVICE" is fine. Atm we
While tracking down various bits of i915 uAPI, it's been difficult to
find the userspace much of the time because no one bothers to mention it
in commit messages. Require the kernel patch to be a one-stop shop for
finding the various bits which were used to justify the new uAPI.
v2 (Daniel
On Wed, Aug 4, 2021 at 8:50 PM Jason Ekstrand wrote:
>
> On Wed, Aug 4, 2021 at 1:48 PM Jason Ekstrand wrote:
> >
> > While tracking down various bits of i915 uAPI, it's been difficult to
> > find the userspace much of the time because no one bothers to mention it
> > in commit messages.
On Wed, Aug 4, 2021 at 1:48 PM Jason Ekstrand wrote:
>
> While tracking down various bits of i915 uAPI, it's been difficult to
> find the userspace much of the time because no one bothers to mention it
> in commit messages. Require the kernel patch to be a one-stop shop for
> finding the various
While tracking down various bits of i915 uAPI, it's been difficult to
find the userspace much of the time because no one bothers to mention it
in commit messages. Require the kernel patch to be a one-stop shop for
finding the various bits which were used to justify the new uAPI.
Signed-off-by:
Hi Thomas,
On Wed, Aug 04, 2021 at 08:30:41PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 03.08.21 um 17:00 schrieb Sam Ravnborg:
> > Hi Thomas,
> >
> > On Tue, Aug 03, 2021 at 11:07:01AM +0200, Thomas Zimmermann wrote:
> > > Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's
> >
Hi Dave and Daniel,
Here goes drm-intel-fixes-2021-08-04:
- Call i915_globals_exit if pci_register_device fails (Jason)
- Correct SFC_DONE register offset (Matt)
Thanks,
Rodrigo.
The following changes since commit c500bee1c5b2f1d59b1081ac879d73268ab0ff17:
Linux 5.14-rc4 (2021-08-01 17:04:17
Hi
Am 03.08.21 um 17:00 schrieb Sam Ravnborg:
Hi Thomas,
On Tue, Aug 03, 2021 at 11:07:01AM +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.
DRM IRQ
Hi Artjom,
On Wed, Aug 04, 2021 at 03:23:53AM +0300, Artjom Vejsel wrote:
> The Gopher 2b LCD panel is used in Gopher 2b handhelds.
> It's simple panel with NewVision NV3047 driver, but SPI lines are not
> connected.
> It has no specific name, since it's unique to that handhelds.
> lot name at
On Wed, Aug 04, 2021 at 03:23:52AM +0300, Artjom Vejsel wrote:
> Add DT bindings for QiShenglong Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel.
>
> Signed-off-by: Artjom Vejsel
Reviewed-by: Sam Ravnborg
Paul, I assume you will apply when you are happy with the driver.
Sam
On Wed, Aug 04, 2021 at 03:23:51AM +0300, Artjom Vejsel wrote:
> Add vendor prefix for Shenzhen QiShenglong Industrialist Co., Ltd.
> QiShenglong is a Chinese manufacturer of handheld gaming consoles, most of
> which run (very old) versions of Linux.
> QiShenglong is known as Hamy.
>
>
Hi Sam
Am 03.08.21 um 18:21 schrieb Sam Ravnborg:
Hi Thomas,
On Tue, Aug 03, 2021 at 02:59:17PM +0200, Thomas Zimmermann wrote:
A framebuffer's offsets field might be non-zero to make the BO data
start at the specified offset within the BO's memory. Handle this
case in drm_gem_fb_vmap() and
Hi,
just a friendly reminder that branches that end with -fixes are for
fixes that are required in upstream ASAP. I found this patch in
drm-misc-fixes. It's not important, so it should have gone into
drm-misc-next instead.
Best regards
Thomas
Am 28.07.21 um 02:31 schrieb Anitha
Hi Dave and Daniel,
here's the weekly PR for drm-misc-fixes. I cherry-picked the vmwgfx
fix from drm-misc-next-fixes where it accidentally landed first.
Best regards
Thomas
drm-misc-fixes-2021-08-04:
Short summary of fixes pull:
* kmb: DMA fix; Add macros for driver date/version
* vmwgfx:
Quoting Kuogee Hsieh (2021-08-04 08:51:01)
> Currently at dp_pm_resume() is_connected state is decided base on hpd
> connection
> status only. This will put is_connected in wrongly "true" state at the
> scenario
> that dongle attached to DUT but without hmdi cable connecting to it. Fix this
>
Quoting khs...@codeaurora.org (2021-08-04 08:48:04)
> On 2021-08-03 12:05, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2021-08-03 09:25:13)
> >> @@ -1327,14 +1327,26 @@ static int dp_pm_resume(struct device *dev)
> >>
> >> dp_catalog_ctrl_hpd_config(dp->catalog);
> >>
> >> - status
Hi Shawn,
see a few comments in the following.
Sam
On Wed, Aug 04, 2021 at 04:13:52PM +0800, Shawn Guo wrote:
> It adds a drm driver for Truly NT35521 5.24" 1280x720 DSI panel, which
> can be found on Sony Xperia M4 Aqua phone. The panel backlight is
> managed through DSI link.
>
>
Hi Shawn,
On Wed, Aug 04, 2021 at 04:13:51PM +0800, Shawn Guo wrote:
> The Truly NT35521 is a 5.24" 1280x720 DSI panel, and the backlight is
> managed through DSI link.
>
> Signed-off-by: Shawn Guo
Please consider adding an optional port node, so we can use this panels
in a setup using a
Currently at dp_pm_resume() is_connected state is decided base on hpd connection
status only. This will put is_connected in wrongly "true" state at the scenario
that dongle attached to DUT but without hmdi cable connecting to it. Fix this
problem by adding read sink count from dongle and decided
On 2021-08-03 12:05, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2021-08-03 09:25:13)
Currently at dp_pm_resume() is_connected state is decided base on hpd
connection
status only. This will put is_connected in wrongly "true" state at the
scenario
that dongle attached to DUT but without hmdi
On Tue, Aug 03, 2021 at 10:49:39AM -0400, Alex Deucher wrote:
> On Tue, Aug 3, 2021 at 4:34 AM Michel Dänzer wrote:
> >
> > On 2021-08-02 4:51 p.m., Alex Deucher wrote:
> > > On Mon, Aug 2, 2021 at 4:31 AM Daniel Vetter wrote:
> > >>
> > >> On Mon, Aug 02, 2021 at 10:12:47AM +0200, Christian
Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
fast+narrow link on eDP again and fall back to the old max strategy on
failure"), the screen starts to have wobbly effect.
Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
everything") doesn't help either,
Using the generic extension support set in the previous patch, this
patch enables more than one in/out binary syncobj per job submission.
Arrays of syncobjs are set in a specific extension type (multisync)
that also cares of determining the stage for sync (bin/render)
through a flag - when this is
Add support to attach generic extensions on job submission.
This patch is a second prep work to enable multiple syncobjs on job
submission. With this work, when the job submission interface needs
to be extended to accomodate a new feature, we will use a generic
extension struct where an id
Prep work to enable multiple syncobj as job dependency.
Also get rid of old checkpatch warnings in the v3d_gem file.
No functional changes.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/v3d/v3d_gem.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff
Hi,
Currently, v3d only supports single in/out syncobj per submission (in
v3d_submit_cl we have two in_sync, one for bin and another for render
job); however, Vulkan queue submit operations expect multiples wait and
signal semaphores. This series extending v3d interface and job
dependency
On Wed, Aug 4, 2021 at 4:19 PM Arnd Bergmann wrote:
>
> On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
> >
> > playing around a little bit with this, I think the original "select
> > BACKLIGHT_CLASS_DEVICE" is fine. Atm we kind of have this weird mix of
> > drivers selecting and others
On Wed, Aug 4, 2021 at 10:00 AM Thomas Hellström
wrote:
>
> Hi,
>
> On 7/22/21 11:59 AM, Matthew Auld wrote:
> > On Thu, 22 Jul 2021 at 10:49, Matthew Auld
> > wrote:
> >> On Wed, 21 Jul 2021 at 21:11, Jason Ekstrand wrote:
> >>> On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
> >>> wrote:
>
There's quite a fundamental difference between userspace contexts, and
kernel contexts. Latter all share intel_gt->vm, former get their vm
from gem_ctx->vm (on full ppgtt at least).
By splitting context creation for userspace from kernel-internal ones
we can make this all a bit more strict and
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
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
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.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
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
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
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
Hi all,
Next round with some fixes:
- missed a conversion, 0day spotted it running sparse
- missed virtual engines in the last patch, intel-gfx-ci spotted that too
(except it was mostly filtered out by a bogus cibuglog entry, so took a
while to realize what's going on).
Old version:
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
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
On Wed, Aug 4, 2021 at 4:10 PM Karol Herbst wrote:
>
> playing around a little bit with this, I think the original "select
> BACKLIGHT_CLASS_DEVICE" is fine. Atm we kind of have this weird mix of
> drivers selecting and others depending on it. We could of course convert
> everything over to
Hi Maxime,
I have been busy with other tasks, and I did not follow the list last
time, so sorry for my late response.
On 28.07.2021 15:32, Maxime Ripard wrote:
> Hi,
>
> We've encountered an issue with the RaspberryPi DSI panel that prevented the
> whole display driver from probing.
>
> The
playing around a little bit with this, I think the original "select
BACKLIGHT_CLASS_DEVICE" is fine. Atm we kind of have this weird mix of
drivers selecting and others depending on it. We could of course convert
everything over to depend, and break those cycling dependency issues with
this.
On Wed, Aug 4, 2021 at 6:36 AM Oleksij Rempel wrote:
>
> changes v4:
> - add vref-supply to adc@0
> - split gpio assignment for the mdio node
Hi Oleksij,
I've dropped the series from the soc patchwork, since this looks like
something that
should go through the i.MX tree. Please make it clear
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #36 from Jerome C (m...@jeromec.com) ---
I've been watching linux-next and noticed that this commit
https://bugzilla.kernel.org/show_bug.cgi?id=208981
--- Comment #10 from Florian La Roche (florian.laro...@gmail.com) ---
This seems to be fixed after updating to BIOS F12 from 2021-01-18,
BIOS Revision: 5.17.
There are even newer BIOS revisions available, but they only work with RAM at
2133 MT/s
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #35 from kolAflash (kolafl...@kolahilft.de) ---
Created attachment 298193
--> https://bugzilla.kernel.org/attachment.cgi?id=298193=edit
/var/log/kern.log running amd-drm-next-5.14-2021-05-12 (ae30d41eb) with Xorg
Sorry for the long
Hi Shawn,
Thanks for the patch!
On Wed, Aug 04, 2021 at 04:13:52PM +0800, Shawn Guo wrote:
> It adds a drm driver for Truly NT35521 5.24" 1280x720 DSI panel, which
> can be found on Sony Xperia M4 Aqua phone. The panel backlight is
> managed through DSI link.
>
> Signed-off-by: Shawn Guo
>
On Tue, Aug 3, 2021 at 9:34 AM Michel Dänzer wrote:
> On 2021-08-03 8:11 a.m., Kasireddy, Vivek wrote:
> >>> The goal:
> >>> - Maintain full framerate even when the Guest scanout FB is flipped onto
> >>> a hardware
> >> plane
> >>> on the Host -- regardless of either compositor's scheduling
Add safe lut configuration for all the targets in dpu
driver as per QOS recommendation.
Issue reported on SC7280:
With wait-for-safe feature in smmu enabled, RT client
buffer levels are checked to be safe before smmu invalidation.
Since display was always set to unsafe it was delaying the
On Wed, Aug 04, 2021 at 01:38:33AM -0700, Kalyan Thota wrote:
> Add safe lut configuration for all the targets in dpu
> driver as per QOS recommendation.
>
> Issue reported on SC7280:
>
> With wait-for-safe feature in smmu enabled, RT client
> buffer levels are checked to be safe before smmu
On Wed, Aug 04, 2021 at 01:16:30AM -0700, Kalyan Thota wrote:
> Add safe lut configuration for all the targets in dpu
> driver as per QOS recommendation.
>
> Issue reported on SC7280:
>
> With wait-for-safe feature in smmu enabled, RT client
> buffer levels are checked to be safe before smmu
Add safe lut configuration for all the targets in dpu
driver as per QOS recommendation.
Issue reported on SC7280:
With wait-for-safe feature in smmu enabled, RT client
buffer levels are checked to be safe before smmu invalidation.
Since display was always set to unsafe it was delaying the
Add safe lut configuration for all the targets in dpu
driver as per QOS recommendation.
Issue reported on SC7280:
With wait-for-safe feature in smmu enabled, RT client
buffer levels are checked to be safe before smmu invalidation.
Since display was always set to unsafe it was delaying the
It adds a drm driver for Truly NT35521 5.24" 1280x720 DSI panel, which
can be found on Sony Xperia M4 Aqua phone. The panel backlight is
managed through DSI link.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/panel/Kconfig | 9 +
drivers/gpu/drm/panel/Makefile | 1
The Truly NT35521 is a 5.24" 1280x720 DSI panel, and the backlight is
managed through DSI link.
Signed-off-by: Shawn Guo
---
.../bindings/display/panel/truly,nt35521.yaml | 62 +++
1 file changed, 62 insertions(+)
create mode 100644
It adds a drm driver for Truly NT35521 5.24" 1280x720 DSI panel, which
can be found on Sony Xperia M4 Aqua phone.
Shawn Guo (2):
dt-bindings: display: panel: Add Truly NT35521 panel support
drm/panel: Add Truly NT35521 panel driver
.../bindings/display/panel/truly,nt35521.yaml | 62 +++
Hi,
On 7/22/21 11:59 AM, Matthew Auld wrote:
On Thu, 22 Jul 2021 at 10:49, Matthew Auld
wrote:
On Wed, 21 Jul 2021 at 21:11, Jason Ekstrand wrote:
On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
wrote:
On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote:
On Fri, Jul 16, 2021 at 1:45 PM
On Mon, Aug 2, 2021 at 4:53 PM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> Another missed dependency when SCM is a loadable module
> and adreno is built-in:
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.o: In function `adreno_zap_shader_load':
> adreno_gpu.c:(.text+0x1e8): undefined reference
Hi
can you please test if your device still work after applying this
https://patchwork.kernel.org/project/linux-mediatek/patch/20210729070549.5514-1-li...@fw-web.de/
and
duplicate value constants in your routes?
e.g. changing
+ DDP_COMPONENT_OVL_2L0, DDP_COMPONENT_RDMA0,
+
Hi Gerd,
>
> > > virtio_gpu_primary_plane_update() will send RESOURCE_FLUSH only for
> > > DIRTYFB and both SET_SCANOUT + RESOURCE_FLUSH for page-flip, and I
> > > think for the page-flip case the host (aka qemu) doesn't get the
> > > "wait until old framebuffer is not in use any more" right
Hi Michel,
> >
> >>> The goal:
> >>> - Maintain full framerate even when the Guest scanout FB is flipped onto
> >>> a hardware
> >> plane
> >>> on the Host -- regardless of either compositor's scheduling policy --
> >>> without making
> any
> >>> copies and ensuring that both Host and Guest are
Hi
Am 03.08.21 um 20:36 schrieb Chrisanthus, Anitha:
Hi Thomas,
Can you please hold off on applying the kmb patch, I am seeing some issues
while testing. Modetest works, but video playback only plays once, and it fails
the second time with this patch.
Sounds a bit like the testing issue at
[Public]
> -Original Message-
> From: Lyude Paul
> Sent: Wednesday, August 4, 2021 8:09 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerry
> ; Wu, Hersen ; Juston Li
> ; Imre Deak ;
> Ville Syrjälä ; Wentland, Harry
> ;
On 8/4/21 8:49 AM, Thomas Hellström wrote:
Hi, Jason,
On 7/16/21 12:38 AM, Jason Ekstrand wrote:
__i915_gem_ttm_object_init() was ignoring the placement requests coming
from the client and always placing all BOs in SMEM upon creation.
Instead, compute the requested placement set from the
Hi, Jason,
On 7/16/21 12:38 AM, Jason Ekstrand wrote:
__i915_gem_ttm_object_init() was ignoring the placement requests coming
from the client and always placing all BOs in SMEM upon creation.
Instead, compute the requested placement set from the object and pass
that into ttm_bo_init_reserved().
Am 04.08.21 um 03:51 schrieb Tuo Li:
The varialbe gtt in the function amdgpu_ttm_tt_populate() and
amdgpu_ttm_tt_unpopulate() is guaranteed to be not NULL in the context.
Thus the null-pointer checks are redundant and can be dropped.
Reported-by: TOTE Robot
Signed-off-by: Tuo Li
80 matches
Mail list logo
