'--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/suijingfeng/drm-add-kms-driver-for-loongson-display-controller/20230202-011138
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link
On 02/02/2023 21:41, Justin Green wrote:
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
On Fri, Feb 03, 2023 at 08:15:42AM +0100, Christoph Hellwig wrote:
> On Fri, Jan 13, 2023 at 08:12:44AM +0100, Greg Kroah-Hartman wrote:
> > Do you want all of these to go through a single tree, or can they go
> > through the different driver subsystem trees?
>
> Looks like the big removal isn't
Hi Rob,
On 30-Jan-23 22:34, Rob Herring wrote:
> On Tue, Jan 24, 2023 at 03:42:37PM +0530, Aradhya Bhatia wrote:
>> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
>> one link, and odd pixels on the other. These panels are also generic in
>> nature, with no documented
Hi Linus,
A few more fixes this week, a bit more spread out though. We have a
bunch of nouveau regression and stabilisation fixes, along with usual
amdgpu, and i915. Otherwise just some minor misc ones.
Dave.
drm-fixes-2023-02-03:
drm fixes for 6.2-rc7
dma-fence:
- fix signaling bit for
Hi all,
After merging the drm tree, today's linux-next build (htmldocs) produced
this warning:
Documentation/gpu/i915:64: drivers/gpu/drm/i915/gt/intel_workarounds.c:32:
WARNING: Inline emphasis start-string without end-string.
Documentation/gpu/i915:64:
Userspace has no way of controlling or knowing the pixel encoding
currently, so there is no way for it to ever get the right values here.
When we do add pixel_encoding control from userspace,we can pick the
right value for the colorimetry packet based on the
pixel_encoding + the colorspace.
To match the other enums, and add more information about these values.
Signed-off-by: Joshua Ashton
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
From: Harry Wentland
This allows us to use strongly typed arguments.
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-devel@lists.freedesktop.org
Cc:
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. So, replace one-element array with flexible-array
member in struct vmw_view.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards
On Thu, Feb 02, 2023 at 04:57:08PM -0800, Lucas De Marchi wrote:
> 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
From: John Harrison
The comparison in the search for a matching register capture node was
not the most readable. So remove two redundant terms and re-format to
keep each term on a single line, and only one term per line.
Signed-off-by: John Harrison
---
From: John Harrison
Ecodes got lost with the switch to GuC based register lists. Put them
back.
Seqno values got lost with the switch to per context timelines. Put
hose back too.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc: Fix missing ecodes
drm/i915/guc: Clean up of
From: John Harrison
Error captures are tagged with an 'ecode'. This is a pseduo-unique magic
number that is meant to distinguish similar seeming bugs with
different underlying signatures. It is a combination of two ring state
registers. Unfortunately, the register state being used is only valid
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
---
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
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 +
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
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
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
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 ++--
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
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
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
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
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
---
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 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 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)
> ---
>
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.
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.
> 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
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
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
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.
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
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/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
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,
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
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
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
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.
> >
> >
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
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
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.
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
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
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
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 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
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
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:
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
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:
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
>
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:
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
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
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
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
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.
[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;
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.
>
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))
+
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:
-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/make.cross
On 02/02/2023 08:58, Christian König wrote:
> [...]
>> +if (!ring->no_scheduler && ring->sched.ops)
>> drm_sched_fini(>sched);
>
> I think we should drop the check for no_scheduler here and just call
> drm_sched_fini() when the scheduler instance was initialized
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
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
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
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
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 +
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
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
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
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-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
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
%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
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
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
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
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:
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
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
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
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
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
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'
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
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
---
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
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
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
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
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
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
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
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
---
1 - 100 of 114 matches
Mail list logo
