Hi Sumit, all
Upstream OP-TEE should support registering a dmabuf since a while, given how
widely dmabuf is used in Linux for passing buffers around between devices.
Purpose of the new register_tee_shm ioctl is to allow OPTEE to use memory
allocated from the exiting linux dma buffer. We don't n
MESA driver is creating protected context on every driver handle
initialization to query caps bit for app. So when running CI tests,
they are observing hundreds of drm_errors when enabling PXP
in .config but using SOC or BIOS configuration that cannot support
PXP sessions.
Update error handling co
Hi Dave and Daniel,
here's the first PR for drm-misc-next-fixes for this release cycle.
Best regards
Thomas
drm-misc-next-fixes-2023-02-02:
Short summary of fixes pull:
A number of simple fixes throughout the DRM codebase.
The following changes since commit aebd8f0c6f8280ba35bc989f4a9ea47469d35
Hi Andi,
You gave a lot of explanations, and confirmed that this patch solves the
problem, but the root cause of this problem still seems to be unclear.
In the logs where this problem was reported, the logs were output in the
following order.
link
:
https://intel-gfx-ci.01.org/tree/drm-ti
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each
On 02/02/2023 07:43, Andrzej Hajda wrote:
On 01.02.2023 17:51, Tvrtko Ursulin wrote:
[snip]
+static int intel_engine_init_tlb_invalidation(struct intel_engine_cs
*engine)
+{
+ static const union intel_engine_tlb_inv_reg gen8_regs[] = {
+ [RENDER_CLASS].reg = GEN8_RTCR,
+
looks good to me, but could you please add bpsec# to commit log?
Reviewed-by: Gwan-gyeong Mun
On 2/2/23 4:52 AM, Ashutosh Dixit wrote:
Previous documentation suggested that PL1 power limit is always
enabled. However we now find this not to be the case on some
platforms (such as ATSM). Therefor
Hi Cyrille,
Please don't top post as it makes it harder to follow-up.
On Thu, 2 Feb 2023 at 13:26, Cyrille Fleury wrote:
>
> Hi Sumit, all
>
> Upstream OP-TEE should support registering a dmabuf since a while, given how
> widely dmabuf is used in Linux for passing buffers around between devices
On 02/02/2023 08:13, Alan Previn wrote:
MESA driver is creating protected context on every driver handle
initialization to query caps bit for app. So when running CI tests,
they are observing hundreds of drm_errors when enabling PXP
in .config but using SOC or BIOS configuration that cannot sup
On Wed, 1 Feb 2023 18:06:41 -0800
Jessica Zhang wrote:
> On 1/31/2023 4:49 AM, Pekka Paalanen wrote:
> > On Tue, 31 Jan 2023 11:21:18 +
> > Simon Ser wrote:
> >
> >> On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen
> >> wrote:
> >>
> >>> On Tue, 31 Jan 2023 10:06:39 +
> >>>
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2023-02-02:
A fix for a non-unique CEC adapter name registration in vc4, a
regression breaking the display in ssd130x, a signaling bit issue in
dma-fence, a couple of fixes in nouveau for Turing and Ampere, and a
disable fix for the bo
Il 02/02/23 05:57, Chen-Yu Tsai ha scritto:
The MediaTek DisplayPort interface bridge driver starts its interrupts
as soon as its probed. However when the interrupts trigger the bridge
might not have been attached to a DRM device. As drm_helper_hpd_irq_event()
does not check whether the passed in
Few fixes intended for 6.3.
Andrzej Kacprowski (2):
accel/ivpu: Fix FW API data alignment issues
accel/ivpu: Send VPU_JSM_MSG_CONTEXT_DELETE when deleting context
Stanislaw Gruszka (2):
accel/ivpu: Set dma max_segment_size
accel/ivpu: Fix old dma_buf api usage
drivers/accel/ivpu/ivpu_dr
From: Andrzej Kacprowski
FW API structures have been updated to fix misaligned
structure members.
Also changed JSM message header format to account for
future improvements.
Added explicit check for minimum supported JSM API version.
Signed-off-by: Andrzej Kacprowski
Signed-off-by: Stanislaw G
Avoid below spurious warning:
[ 264.844029] DMA-API: intel_vpu :00:0b.0: mapping sg segment longer than
device claims to support [len=143360] [max=65536]
[ 264.844038] WARNING: CPU: 0 PID: 1254 at kernel/dma/debug.c:1160
debug_dma_map_sg+0x6ca/0xb70
Signed-off-by: Stanislaw Gruszka
---
From: Andrzej Kacprowski
The VPU_JSM_MSG_CONTEXT_DELETE will remove any resources associated
with the SSID, that included any blobs create by the user space
application.
The command can also remove doorbell registrations, but since this
does not work in HW scheduling case, we do not depend on th
Update according to new dma-buf locking scheme.
Remove redundant WARN_ON()'s, dma_buf functions internally
have the same warnings already.
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_gem.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/accel
Hi GG,
On Thu, Feb 02, 2023 at 10:22:30AM +0200, Gwan-gyeong Mun wrote:
> Hi Andi,
>
> You gave a lot of explanations, and confirmed that this patch solves the
> problem, but the root cause of this problem still seems to be unclear.
>
> In the logs where this problem was reported, the logs were
Il 27/12/22 09:10, Nancy.Lin ha scritto:
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Hello Chun-Kuang,
This series reached version 29 and was tested for a long ti
On 02.02.2023 09:33, Tvrtko Ursulin wrote:
On 02/02/2023 07:43, Andrzej Hajda wrote:
On 01.02.2023 17:51, Tvrtko Ursulin wrote:
[snip]
Btw - do you have any idea why the test is suppressed already?! CI told
me BAT was a success...
Except this patch, igt@i915_selftest@live@gt_tlb always
On 02/02/2023 05:57, Chen-Yu Tsai wrote:
The MediaTek DisplayPort interface bridge driver starts its interrupts
as soon as its probed. However when the interrupts trigger the bridge
might not have been attached to a DRM device. As drm_helper_hpd_irq_event()
does not check whether the passed in
On Thu, 2 Feb 2023 at 09:35, Sumit Garg wrote:
>
> Hi Cyrille,
>
> Please don't top post as it makes it harder to follow-up.
>
> On Thu, 2 Feb 2023 at 13:26, Cyrille Fleury wrote:
> >
> > Hi Sumit, all
> >
> > Upstream OP-TEE should support registering a dmabuf since a while, given
> > how widel
On 01/02/2023 18:02, Justin Green wrote:
Add an DDP component interface for querying pixel format support and move list
of supported pixel formats into DDP components instead of mtk_drm_plane.c
Tested by running Chrome on an MT8195.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek
On 01/02/2023 18:02, Justin Green wrote:
Tested using "modetest -P" on an MT8195 device.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl
From: Arnd Bergmann
In configurations with CONFIG_KUNIT=m, builting the unit test
into the kernel causes a link failure:
arm-linux-gnueabi-ld: drivers/gpu/drm/vc4/tests/vc4_mock.o: in function
`__build_mock':
vc4_mock.c:(.text+0x6e): undefined reference to `kunit_do_failed_assertion'
arm-linux-
On 2/2/23 11:28 AM, Andi Shyti wrote:
Hi GG,
On Thu, Feb 02, 2023 at 10:22:30AM +0200, Gwan-gyeong Mun wrote:
Hi Andi,
You gave a lot of explanations, and confirmed that this patch solves the
problem, but the root cause of this problem still seems to be unclear.
In the logs where this prob
Commit 8fc0380f6ba7 ("drm/client: Add some tests for
drm_connector_pick_cmdline_mode()") was meant to introduce unit tests
for the static drm_connector_pick_cmdline_mode() function.
In such a case, the kunit documentation recommended to import the tests
source file directly from the source file wi
On 2/1/23 04:10, Thomas Zimmermann wrote:
Am 30.01.23 um 13:55 schrieb Maíra Canal:
Commit b8a926bea8b1 ("kunit: Introduce KUNIT_EXPECT_MEMEQ and
KUNIT_EXPECT_MEMNEQ macros") introduced a new macro to compare blocks of
memory and, if the test fails, print the result in a human-friendly
format.
Hi Maxime,
On 2/2/23 08:03, Maxime Ripard wrote:
Commit 8fc0380f6ba7 ("drm/client: Add some tests for
drm_connector_pick_cmdline_mode()") was meant to introduce unit tests
for the static drm_connector_pick_cmdline_mode() function.
In such a case, the kunit documentation recommended to import th
Currently, the array of BOs that are lookup up at the start of exec is being
instantiated as drm_gem_dma_object, which is not needed and makes it difficult
to use the drm_gem_objects_lookup() helper. Therefore, replace
drm_gem_dma_object for drm_gem_object and then replace obj lookup steps with
drm
The array of BOs that are lookup at the start of exec doesn't need
to be instantiated as drm_gem_dma_object, as it doesn't benefit
from its attributes. So, simplify the code by replacing the array of
drm_gem_dma_object for an array of drm_gem_object in the struct
vc4_exec_info.
Suggested-by: Melis
As vc4_cl_lookup_bos() performs the same steps as drm_gem_objects_lookup(),
replace the open-coded implementation in vc4 to simply use the DRM function.
Signed-off-by: Maíra Canal
Reviewed-by: André Almeida
---
drivers/gpu/drm/vc4/vc4_gem.c | 43 ++-
1 file chang
Am 01.02.23 um 09:10 schrieb Dave Airlie:
[SNIP]
For drivers that don't intend to merge at all and (somehow) are
capable of dealing with sparse regions without knowing the sparse
region's boundaries, it'd be easy to make those gpuva_regions optional.
Yeah, but this then defeats the approach of
Am 01.02.23 um 17:48 schrieb Guilherme G. Piccoli:
Currently amdgpu calls drm_sched_fini() from the fence driver sw fini
routine - such function is expected to be called only after the
respective init function - drm_sched_init() - was executed successfully.
Happens that we faced a driver probe f
%40intel.com
patch subject: [PATCH v2 11/17] drm/display/dp_mst: Add helpers to query for
payload allocation errors
config: x86_64-randconfig-m001
(https://download.01.org/0day-ci/archive/20230202/202302021855.yyqieq2o-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
If you fix the issue
Hi
Am 02.02.23 um 12:03 schrieb Maxime Ripard:
Commit 8fc0380f6ba7 ("drm/client: Add some tests for
drm_connector_pick_cmdline_mode()") was meant to introduce unit tests
for the static drm_connector_pick_cmdline_mode() function.
In such a case, the kunit documentation recommended to import the
drm-tip drm-tip
> patch link:
> https://lore.kernel.org/r/20230131150548.1614458-12-imre.deak%40intel.com
> patch subject: [PATCH v2 11/17] drm/display/dp_mst: Add helpers to query for
> payload allocation errors
> config: x86_64-randconfig-m001
> (https://download.01.org/0day
Hi,
On Thu, Feb 02, 2023 at 01:22:01PM +0100, Thomas Zimmermann wrote:
> Am 02.02.23 um 12:03 schrieb Maxime Ripard:
> > Commit 8fc0380f6ba7 ("drm/client: Add some tests for
> > drm_connector_pick_cmdline_mode()") was meant to introduce unit tests
> > for the static drm_connector_pick_cmdline_mode
On Thu, Feb 02, 2023 at 08:31:27AM -0300, Maíra Canal wrote:
> Hi Maxime,
>
> On 2/2/23 08:03, Maxime Ripard wrote:
> > Commit 8fc0380f6ba7 ("drm/client: Add some tests for
> > drm_connector_pick_cmdline_mode()") was meant to introduce unit tests
> > for the static drm_connector_pick_cmdline_mode(
On Thu, 02 Feb 2023 11:23:32 +0100, Arnd Bergmann wrote:
> In configurations with CONFIG_KUNIT=m, builting the unit test
> into the kernel causes a link failure:
>
> arm-linux-gnueabi-ld: drivers/gpu/drm/vc4/tests/vc4_mock.o: in function
> `__build_mock':
> vc4_mock.c:(.text+0x6e): undefined refe
There is a spelling mistake in a literal string. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c
b/drivers/gpu/drm/i915/gvt/firmware.c
index dce93738e98a..4dd52a
vgem_fence_open() instantiates a mutex for a particular fence
instance, but never destroys it by calling mutex_destroy() in
vgem_fence_close().
So, add the missing mutex_destroy() to guarantee proper resource
destruction.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/vgem/vgem_fence.c | 1 +
1
Hi
Am 02.02.23 um 13:35 schrieb Maxime Ripard:
Hi,
On Thu, Feb 02, 2023 at 01:22:01PM +0100, Thomas Zimmermann wrote:
Am 02.02.23 um 12:03 schrieb Maxime Ripard:
Commit 8fc0380f6ba7 ("drm/client: Add some tests for
drm_connector_pick_cmdline_mode()") was meant to introduce unit tests
for the
Hi Maxime,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next
drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.2-rc6
next-20230202]
[If your patch is applied to the wrong git
Hi Dave and Daniel,
Here goes this week's fixes with couple targeting stable.
drm-intel-fixes-2023-02-02:
- Fixes for potential use-after-free and double-free (Rob)
- GuC locking and refcount fixes (John)
- Display's reference clock value fix (Chaitanya)
Thanks,
Rodrigo.
The following changes
Currently amdgpu calls drm_sched_fini() from the fence driver sw fini
routine - such function is expected to be called only after the
respective init function - drm_sched_init() - was executed successfully.
Happens that we faced a driver probe failure in the Steam Deck
recently, and the function d
On 02/02/2023 08:58, Christian König wrote:
> [...]
>> +if (!ring->no_scheduler && ring->sched.ops)
>> drm_sched_fini(&ring->sched);
>
> I think we should drop the check for no_scheduler here and just call
> drm_sched_fini() when the scheduler instance was initial
fig: arm64-randconfig-r034-20230129
(https://download.01.org/0day-ci/archive/20230202/202302022254.37xyfgnr-...@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
Cc: Zhenyu Wang
Cc: Zhi Wang
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc:
On 28/01/2023 01:11, Tejun Heo wrote:
On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin wrote:
...
+ /*
+* 1st pass - reset working values and update hierarchical weights and
+* GPU utilisation.
+*/
+ if (!__start_scanning(root, period_us))
+
On Thu, Feb 02, 2023 at 09:55:17AM -0300, Maíra Canal wrote:
> vgem_fence_open() instantiates a mutex for a particular fence
> instance, but never destroys it by calling mutex_destroy() in
> vgem_fence_close().
>
> So, add the missing mutex_destroy() to guarantee proper resource
> destruction.
>
[Public]
> -Original Message-
> From: dim-tools On Behalf Of
> John Paul Adrian Glaubitz
> Sent: Monday, January 23, 2023 10:01 AM
> To: tzimmerm...@suse.de
> Cc: tvrtko.ursu...@linux.intel.com; dim-to...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; intel-...@lists.freedesktop.org; dr
On 2/2/2023 2:21 AM, Stanislaw Gruszka wrote:
From: Andrzej Kacprowski
FW API structures have been updated to fix misaligned
structure members.
Also changed JSM message header format to account for
future improvements.
Added explicit check for minimum supported JSM API version.
Signed-off-by
On 2/2/2023 2:21 AM, Stanislaw Gruszka wrote:
From: Andrzej Kacprowski
The VPU_JSM_MSG_CONTEXT_DELETE will remove any resources associated
with the SSID, that included any blobs create by the user space
application.
The command can also remove doorbell registrations, but since this
does not wo
On 2/2/2023 2:21 AM, Stanislaw Gruszka wrote:
Avoid below spurious warning:
[ 264.844029] DMA-API: intel_vpu :00:0b.0: mapping sg segment longer than
device claims to support [len=143360] [max=65536]
[ 264.844038] WARNING: CPU: 0 PID: 1254 at kernel/dma/debug.c:1160
debug_dma_map_sg+0x6c
On 2/2/2023 2:21 AM, Stanislaw Gruszka wrote:
Update according to new dma-buf locking scheme.
Remove redundant WARN_ON()'s, dma_buf functions internally
have the same warnings already.
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Jeffrey Hugo
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: ea4dabbb4ad7eb52632a2ca0b8f89f0ea7c55dcf Add linux-next specific
files for 20230202
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202301301801.y5o08tqx-...@intel.com
https
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:15:58PM -0800, Niranjana Vishwanathapura wrote:
> Update the execbuf path to use common execbuf functions to
> reduce code duplication with the newer execbuf3 path.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: An
Hi Guilherme,
Thanks for redoing to a v3. This patch is:
Reviewed-by: Luben Tuikov
Regards,
Luben
On 2023-02-02 08:48, Guilherme G. Piccoli wrote:
> Currently amdgpu calls drm_sched_fini() from the fence driver sw fini
> routine - such function is expected to be called only after the
> respect
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:04PM -0800, Niranjana Vishwanathapura wrote:
> Only support vm_bind mode with non-recoverable contexts.
> With new vm_bind mode with eb3 submission path, we need not
> support older recoverable contexts.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: N
Previous documentation suggested that PL1 power limit is always
enabled. However we now find this not to be the case on some
platforms (such as ATSM). Therefore enable PL1 power limit during hwmon
initialization.
Bspec: 51864
v2: Add Bspec reference (Gwan-gyeong)
Signed-off-by: Ashutosh Dixit
R
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:06PM -0800, Niranjana Vishwanathapura wrote:
> Update i915 documentation to include VM_BIND changes
> and render all VM_BIND related documentation.
>
> Reviewed-by: Matthew Auld
> Signed-off-by: Niranjana Vishwanathapura
looks good!
Reviewed-by: And
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:08PM -0800, Niranjana Vishwanathapura wrote:
> Properly build the sg table for persistent mapping which can
> be partial map of the underlying object. Ensure the sg pages
> are properly set for page backed regions. The dump capture
> support requires thi
Hi Maxime,
On Mon, Jan 30, 2023 at 6:28 PM Maxime Ripard wrote:
>
> On Thu, Jan 26, 2023 at 08:48:48PM +0530, Jagan Teki wrote:
> > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote:
> > > > Add devm OF hel
On 02/02/2023 13:12, Luben Tuikov wrote:
> Hi Guilherme,
>
> Thanks for redoing to a v3. This patch is:
>
> Reviewed-by: Luben Tuikov
>
> Regards,
> Luben
>
Thank you for the reviews Luben, much appreciated!
Hi Niranjana,
On Tue, Jan 17, 2023 at 11:16:09PM -0800, Niranjana Vishwanathapura wrote:
> Support dump capture of persistent mappings upon user request.
>
> Capture of a mapping is requested with the VM_BIND ioctl and
> processed during the GPU error handling. They are synchronously
> unbound du
On Thu, 2023-02-02 at 08:43 +, Tvrtko Ursulin wrote:
>
> On 02/02/2023 08:13, Alan Previn wrote:
> > MESA driver is creating protected context on every driver handle
> > initialization to query caps bit for app. So when running CI tests,
> > they are observing hundreds of drm_errors when enabl
DSM granularity is 1MB so make sure we stick to that.
v2: replace "1 * SZ_1M" with SZ_1M (Andrzej).
Cc: Matthew Auld
Suggested-by: Lucas De Marchi
Signed-off-by: Nirmoy Das
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 2 +-
1 file changed, 1 insertion(+), 1 del
On 2/2/23 12:53, Christian König wrote:
Am 01.02.23 um 09:10 schrieb Dave Airlie:
[SNIP]
For drivers that don't intend to merge at all and (somehow) are
capable of dealing with sparse regions without knowing the sparse
region's boundaries, it'd be easy to make those gpuva_regions optional.
Yea
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.
Signed-off-by: Dmitry Baryshkov
Sorry but once again, I dont see a response to my comment
https:
If, for whatever reason, we're trying process adreno_runtime_resume()
at the same time that a6xx_destroy() is running then things can go
boom. Specifically adreno_runtime_resume() will eventually call
a6xx_pm_resume() and that may try to resume the gmu.
Let's grab the GMU lock as we're destroying
Hi Abhinav,
On Thu, 2 Feb 2023 at 20:41, Abhinav Kumar wrote:
>
>
>
> On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
> > Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
> > dpu_hw_sspp_setup_rects() programs only source and destination
> > rectangles.
> >
> > Signed-off-by:
Hi Matthias,
> mt8173_formats are the same as the old struct formats. Maybe we should use
> that
> and only overwrite where we actually use a different array.
I think this was sort of how the original patch worked, but we wanted
to add some flexibility to allow different components to support
dif
On 2/2/2023 10:55 AM, Dmitry Baryshkov wrote:
Hi Abhinav,
On Thu, 2 Feb 2023 at 20:41, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destinatio
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
Remove dpu_hw_fmt_layout instance from struct dpu_hw_pipe_cfg, leaving
only src_rect and dst_rect. This way right and left pipes will have
separate dpu_hw_pipe_cfg isntances, while the layout is common to both
of them.
Sorry for not responding
On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar wrote:
>
>
>
> On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
> > Remove dpu_hw_fmt_layout instance from struct dpu_hw_pipe_cfg, leaving
> > only src_rect and dst_rect. This way right and left pipes will have
> > separate dpu_hw_pipe_cfg isntances, while
On 2/2/2023 11:45 AM, Dmitry Baryshkov wrote:
On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
Remove dpu_hw_fmt_layout instance from struct dpu_hw_pipe_cfg, leaving
only src_rect and dst_rect. This way right and left pipes will have
separ
Hello,
On Thu, Feb 02, 2023 at 02:26:06PM +, Tvrtko Ursulin wrote:
> When you say active/inactive - to what you are referring in the cgroup
> world? Offline/online? For those my understanding was offline was a
> temporary state while css is getting destroyed.
Oh, it's just based on activity.
On 2/1/2023 6:33 AM, Doug Anderson wrote:
Hi,
On Tue, Jan 31, 2023 at 3:32 PM Abhinav Kumar wrote:
On 1/31/2023 2:18 PM, Douglas Anderson wrote:
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
becau
On 02/02/2023 21:54, Abhinav Kumar wrote:
On 2/2/2023 11:45 AM, Dmitry Baryshkov wrote:
On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar
wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
Remove dpu_hw_fmt_layout instance from struct dpu_hw_pipe_cfg, leaving
only src_rect and dst_rect. Thi
On 2/2/2023 12:10 PM, Dmitry Baryshkov wrote:
On 02/02/2023 21:54, Abhinav Kumar wrote:
On 2/2/2023 11:45 AM, Dmitry Baryshkov wrote:
On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar
wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
Remove dpu_hw_fmt_layout instance from struct dpu_hw
On 02/02/2023 19:59, Justin Green wrote:
Hi Matthias,
mt8173_formats are the same as the old struct formats. Maybe we should use that
and only overwrite where we actually use a different array.
I think this was sort of how the original patch worked, but we wanted
to add some flexibility to
> Yes, I had a comment on the naming in that patch. Never the less, I think if
> we
> don't need to "overwrite" the value, we should use just one struct for the
> values instead of copying them to the different .c files and give them SoC
> specific names.
I don't have a very strong opinion about t
Hi Doug
On 1/31/2023 2:18 PM, Douglas Anderson wrote:
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time") the error handling with regards to dsi_mgr_bridge_power_on()
got a bit worse. Specifically if we failed to power the bridge on then
nothing would really notice. The
Hi,
On Thu, Feb 2, 2023 at 2:37 PM Abhinav Kumar wrote:
>
> Hi Doug
>
> On 1/31/2023 2:18 PM, Douglas Anderson wrote:
> > In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
> > time") the error handling with regards to dsi_mgr_bridge_power_on()
> > got a bit worse. Specificall
On Sun, 29 Jan 2023 17:05:37 +0100, Krzysztof Kozlowski wrote:
> Convert the Silicon Image SiI8620 HDMI/MHL bridge bindings to DT schema.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v1:
> 1. Require also port@1 (Laurent)
> ---
> .../bindings/display/bridge/sil,sii8620.ya
On Wed, Feb 1, 2023 at 6:23 AM Tvrtko Ursulin
wrote:
>
>
> On 01/02/2023 01:49, T.J. Mercier wrote:
> > On Tue, Jan 31, 2023 at 6:01 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 25/01/2023 20:04, T.J. Mercier wrote:
> >>> On Wed, Jan 25, 2023 at 9:31 AM Tvrtko Ursulin
> >>> wrote:
>
> >>>
On Wed, Feb 1, 2023 at 6:52 AM Tvrtko Ursulin
wrote:
>
>
> On 01/02/2023 14:23, Tvrtko Ursulin wrote:
> >
> > On 01/02/2023 01:49, T.J. Mercier wrote:
> >> On Tue, Jan 31, 2023 at 6:01 AM Tvrtko Ursulin
> >> wrote:
> >>>
> >>>
> >>> On 25/01/2023 20:04, T.J. Mercier wrote:
> On Wed, Jan 25,
On 1/31/2023 2:28 PM, Michal Wajdeczko wrote:
Like we did it for GuC, introduce some helper print macros for
HuC to have unified format of messages that also include GT#.
While around improve some messages and use %pe if possible.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
dri
From: John Harrison
Update more print messages to the new scheme.
Signed-off-by: John Harrison
John Harrison (6):
drm/i915/guc: More debug print updates - UC firmware
drm/i915/guc: More debug print updates - GSC firmware
drm/i915/guc: More debug print updates - GuC reg capture
drm/i91
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 8 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 60 -
2 files changed, 26 insertions(+), 42 deletions(-)
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_gt_print.h | 3 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 3 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_print.h | 3 +++
3 files change
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_capture.c| 51 ---
1 file changed, 21 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_cap
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 35 ++-
.../drm/i915/gt/uc/selftest_guc_hangcheck.c | 23 ++--
.../drm/i915/gt/uc/selftest_guc_multi_l
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 42
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 116 +++
2 files changed, 73 insertions(+), 85 deletions
From: John Harrison
Update a bunch more debug prints to use the new GT based scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c | 8 +++-
drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 7 +++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/dr
Hi,
On Mon, Jan 23, 2023 at 8:05 AM Laurent Pinchart
wrote:
>
> Hi John,
>
> On Mon, Jan 23, 2023 at 12:16:45PM +, John Keeping wrote:
> > On Sun, Jan 22, 2023 at 05:01:27PM +0200, Laurent Pinchart wrote:
> > > On Sat, Jan 21, 2023 at 05:58:11PM +, John Keeping wrote:
> > > > On Sat, Jan
Register 0x9424 is not replicated on any platform, so it shouldn't be
declared with REG_MCR(). Declaring it with _MMIO() is basically
duplicate of the GEN7 version, so just remove the GEN8 and change all
the callers to use the right functions.
Also use intel_uncore_rmw() rather than a read + write
INF_UNIT_LEVEL_CLKGATE is not replicated, but since it's not actually
used it can just be removed.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/i
From: John Harrison
The seqno value actually written out to memory is no longer in the
regular HWSP and therefore no longer visible in an error capture.
Instead, it is now in its own private timeline buffer. So include that
buffer in the capture too.
Signed-off-by: John Harrison
---
drivers/gp
1 - 100 of 114 matches
Mail list logo
