Good morning Jani,
It has been a long time since I wrote the driver, and many many years
since I sent my last kernel patch, so my memory does not serve me very
well, but I will try to shed some light.
On Fri, Sep 1, 2023 at 12:24 PM Jani Nikula wrote:
>
> The driver was originally added in
Hi Adrián,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.5 next-20230831]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> Since kernel version 6.1.50 the VGA console stopped working on all HP
> ProLiant (G6 and G7) servers with [AMD/ATI] ES1000 VGA controller.
>
> No issue with all kernel version 6.1.X before 6.1.50.
> No issue with the kernel
Hi,
On Fri, Sep 1, 2023 at 6:42 AM Doug Anderson wrote:
>
> > > The above solves the problem with panels wanting to power sequence
> > > themselves at remove() time, but not at shutdown() time. Thus we'd
> > > still have a dependency on having all drivers use
> > > drm_atomic_helper_shutdown()
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all()
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all()
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown(), or in this case the
non-atomic equivalent drm_helper_force_disable_all(), at system
shutdown time and at driver remove time. This is important because
drm_helper_force_disable_all()
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at remove time. Let's
add it.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS driver remove comes straight out of the kernel doc "driver
instance
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time
and at driver unbind time. Among other things, this means that if a
panel is in use that it won't be cleanly powered off at system
shutdown time.
The fact
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time
and at driver unbind time. Among other things, this means that if a
panel is in use that it won't be cleanly powered off at system
shutdown time.
The fact
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() (or
drm_helper_force_disable_all() if not using atomic) at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
NOTE: in order to avoid email sending limits on the cover letter, I've
split this patch series in two. Patches that target drm-misc and ones
that don't. The cover letter of the two is identical other than this note.
This patch series came about after a _long_ discussion between me and
Maxime
Based on grepping through the source code this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time
and at driver unbind time. Among other things, this means that if a
panel is in use that it won't be cleanly powered off at system
shutdown time.
The fact
Based on grepping through the source code these drivers appear to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time
and at driver remove (or unbind) time. Among other things, this means
that if a panel is in use that it won't be cleanly powered off at
system shutdown time.
Based on grepping through the source code these drivers appear to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at remove time. Let's
add it.
The fact that we should call drm_atomic_helper_shutdown() in the case
of OS driver remove comes straight out of the kernel doc "driver
instance
Based on grepping through the source code these drivers appear to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system shutdown time.
The fact that we should call
As with other places in the Linux kernel--kfree(NULL) being the most
famous example--it's convenient to treat being passed a NULL argument
as a noop in cleanup functions. Let's make
drm_atomic_helper_shutdown() work like this.
This is convenient for DRM devices that use the "component" model. On
NOTE: in order to avoid email sending limits on the cover letter, I've
split this patch series in two. Patches that target drm-misc and ones
that don't. The cover letter of the two is identical other than this note.
This patch series came about after a _long_ discussion between me and
Maxime
On Fri, Sep 1, 2023 at 5:13 PM Gil Dekel wrote:
>
> On Fri, Sep 1, 2023 at 2:55 PM Rodrigo Vivi wrote:
> >
> > On Thu, Aug 24, 2023 at 04:50:20PM -0400, Gil Dekel wrote:
> > > Before sending a uevent to userspace in order to trigger a corrective
> > > modeset, we change the failing connector's
Thanks Gil for completing the logic here by emitting link status = BAD
even for final link failure state.
On Thu, Aug 24, 2023 at 1:54 PM Gil Dekel wrote:
>
> When a link-training attempt fails, emit a uevent to user space that
> includes the trigger property, which in this case will be
>
On Fri, Sep 1, 2023 at 2:57 PM Rodrigo Vivi wrote:
>
> On Thu, Aug 24, 2023 at 04:50:16PM -0400, Gil Dekel wrote:
> > Instead of silently giving up when all link-training fallback values are
> > exhausted, this patch modifies the fallback's failure branch to reduces
> > both max_link_lane_count
Hi Adrián,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.5 next-20230831]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Fri, Sep 1, 2023 at 2:55 PM Rodrigo Vivi wrote:
>
> On Thu, Aug 24, 2023 at 04:50:20PM -0400, Gil Dekel wrote:
> > Before sending a uevent to userspace in order to trigger a corrective
> > modeset, we change the failing connector's link-status to BAD. However,
> > the downstream MST branch
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master next-20230831]
[cannot apply to v6.5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch,
Hi Thomas,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master next-20230831]
[cannot apply to v6.5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch,
On Thu, Aug 31, 2023 at 6:45 PM Lyude Paul wrote:
>
> On Thu, 2023-08-24 at 04:12 +, Lin, Wayne wrote:
> > [Public]
> >
> > Hi Lyude,
> >
> > I'm afraid that I don't have the permissions to push and would like to have
> > your help. Thanks!
>
> Whoops, sorry I only just noticed this message.
On Thu, Aug 24, 2023 at 9:46 AM Jani Nikula wrote:
>
> Checking edid->input & DRM_EDID_INPUT_DIGITAL is common enough to
> deserve a helper that also lets us abstract the raw EDID a bit better.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Alex Deucher
Seems to be a few additional users of this
On Fri, Sep 1, 2023 at 3:05 PM Rodrigo Vivi wrote:
>
> On Fri, Sep 01, 2023 at 02:38:11PM -0400, Rodrigo Vivi wrote:
> > On Wed, Aug 30, 2023 at 05:41:37PM -0400, Lyude Paul wrote:
> > > Other then the name typo (s/Pual/Paul):
> > >
> > > Signed-off-by: Lyude Paul (just since I co-authored
> > >
On Fri, Sep 01, 2023 at 02:38:11PM -0400, Rodrigo Vivi wrote:
> On Wed, Aug 30, 2023 at 05:41:37PM -0400, Lyude Paul wrote:
> > Other then the name typo (s/Pual/Paul):
> >
> > Signed-off-by: Lyude Paul (just since I co-authored
> > things~)
>
> I believe having the Co-developed-by: in the
On Thu, Aug 31, 2023 at 6:01 PM Alex Hung wrote:
>
>
>
> On 2023-08-30 01:29, Jani Nikula wrote:
> > On Tue, 29 Aug 2023, Alex Hung wrote:
> >> On 2023-08-29 11:03, Jani Nikula wrote:
> >>> On Tue, 29 Aug 2023, Jani Nikula wrote:
> On Tue, 29 Aug 2023, Alex Deucher wrote:
> > On Tue,
On Thu, Aug 24, 2023 at 04:50:16PM -0400, Gil Dekel wrote:
> Instead of silently giving up when all link-training fallback values are
> exhausted, this patch modifies the fallback's failure branch to reduces
> both max_link_lane_count and max_link_rate to zero (0) and continues to
> emit uevents
On Thu, Aug 24, 2023 at 04:50:20PM -0400, Gil Dekel wrote:
> Before sending a uevent to userspace in order to trigger a corrective
> modeset, we change the failing connector's link-status to BAD. However,
> the downstream MST branch ports are left in their original GOOD state.
>
> This patch
-
base-commit: 8e455145d8f163aefa6b9cc29478e0a9f82276e6
change-id: 20230901-zero-init-fourcc-list-test-2c934b6b7eb8
Best regards,
--
Arthur Grillo
On Wed, Aug 30, 2023 at 05:41:37PM -0400, Lyude Paul wrote:
> Other then the name typo (s/Pual/Paul):
>
> Signed-off-by: Lyude Paul (just since I co-authored
> things~)
I believe having the Co-developed-by: in the patches that you helped
out would be nice.
> Reviewed-by: Lyude Paul
>
> I
drm_device *dev, struct dentry
*root)
{
}
#endif
---
base-commit: 8e455145d8f163aefa6b9cc29478e0a9f82276e6
change-id: 20230901-debugfs-fix-unused-function-warning-9ebbecbd6a5a
Best regards,
--
Arthur Grillo
Hi Maíra, thanks for reviewing!
On 8/26/23 10:53 AM, Maíra Canal wrote:
Hi Carlos,
On 8/25/23 13:07, Carlos Eduardo Gallo Filho wrote:
The dev_private member of drm_device is deprecated and its use should
be avoided. Stop using it by embedding the drm_device onto a mock struct
with a void
mtk_drm_find_possible_crtc_by_comp() assumed that the main path will
always have the CRTC with id 0, the ext id 1 and the third id 2. This
is only true if the paths are all available. But paths are optional (see
also comment in mtk_drm_kms_init()), e.g. the main path might not be
enabled or
drm_crtc_from_index(0) might return NULL if there are no CRTCs
registered at all which will lead to a kernel oops in
mtk_drm_crtc_dma_dev_get(). Add the missing return value check.
Fixes: 0d9eee9118b7 ("drm/mediatek: Add drm ovl_adaptor sub driver for MT8195")
Signed-off-by: Michael Walle
From: Pranjal Ramajor Asha Kanojiya
Once a BO is attached with slicing configuration that BO can only be used
for that particular setting. With this new feature user can detach slicing
configuration off an already sliced BO and attach new slicing configuration
using QAIC_ATTACH_SLICE_BO.
This
From: Pranjal Ramajor Asha Kanojiya
qaic_attach_slicing_bo() updates slicing config on BO. Use the existing
function qaic_free_slices_bo() to remove slicing config done in
qaic_attach_slicing_bo().
Use qaic_free_slices_bo() to cleanup release_dbc()
This would be helpful when we introduce a new
From: Pranjal Ramajor Asha Kanojiya
This makes sure that we have a single place to initialize and
re-initialize BO.
Use this new API to cleanup release_dbc()
We will need this for next patch to detach slicing to a BO.
Signed-off-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Jeffrey Hugo
From: Pranjal Ramajor Asha Kanojiya
Variables that are set while adding the corresponding BO in transfer list
should be cleaned when flushing them out of transfer list prematurely.
After this patch we do not need some of the cleanup done in release_dbc()
This patch would also pave the way to
From: Pranjal Ramajor Asha Kanojiya
Once the BO is declared 'sliced' by setting bo->sliced to true we can
perform DMA (QAIC_EXECUTE_BO) operation on that BO. Hence we should
declare a BO sliced after completing all the operations.
Adding BO to its respective DBC list in qaic_attach_slicing_bo()
From: Pranjal Ramajor Asha Kanojiya
Update/Clean up BO metadata in a central location, this will help maintain
the code and looks cleaner.
Use qaic_unprepare_bo() to cleanup release_dbc()
Next few patches will be implementing detach IOCTL which will leverage
this patch.
Signed-off-by: Pranjal
From: Pranjal Ramajor Asha Kanojiya
->size field in struct qaic_bo stores user requested buffer size for
allocate path or size of the dmabuf(PRIME). Now for allocate path driver
allocates a BO of size which is PAGE_SIZE aligned, this size is already
stored in base BO structure (struct
A BO for a QAIC device has two states -
1. Allocated
2. Sliced
A BO can be allocated at any time, and is initialized in the allocated state.
A BO can transition to the sliced state via ATTACH_SLICE_BO. This prepares the
BO for use with an active workload. Currently a BO in the sliced state can
On Thu, Aug 31, 2023 at 11:49:47PM +0200, Helge Deller wrote:
> On 8/31/23 11:02, Helge Deller wrote:
> > On 8/31/23 10:51, Daniel Vetter wrote:
> > > On Thu, Aug 31, 2023 at 08:44:59AM +0200, Jonathan Neuschäfer wrote:
> > > > On Wed, Aug 30, 2023 at 09:10:26AM +0200, Thomas Zimmermann wrote:
> >
The pull request you sent on Fri, 1 Sep 2023 10:04:04 +0200:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-for-6.6-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b84acc11b1c9552c9ca3a099b1610a6018619332
Thank you!
--
(drm_test_fb_xrgb_to_xbgr,
convert_xrgb_gen_params),
+ KUNIT_CASE_PARAM(drm_test_fb_xrgb_to_abgr,
convert_xrgb_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_clip_offset, clip_offset_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_build_fourcc_list,
fb_build_fourcc_list_gen_params),
KUNIT_CASE_PARAM(drm_test_fb_memcpy, fb_memcpy_gen_params),
---
base-commit: 8e455145d8f163aefa6b9cc29478e0a9f82276e6
change-id: 20230901-final-gsoc-395a84443c8f
Best regards,
--
Arthur Grillo
From: Jacek Lawrynowicz
Use struct drm_gem_shmem_object as a base for struct ivpu_bo.
This cuts by 50% the buffer management code.
Signed-off-by: Jacek Lawrynowicz
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/Kconfig| 2 +-
drivers/accel/ivpu/TODO | 1 -
From: Jacek Lawrynowicz
Usages of DRM_IVPU_BO_UNCACHED should be replaced by DRM_IVPU_BO_WC.
There is no functional benefit from DRM_IVPU_BO_UNCACHED if these
buffers are never mapped to host VM.
This allows to cut the buffer handling code in the kernel driver
by half.
Signed-off-by: Jacek
From: Jacek Lawrynowicz
ivpu_bo_remove_all_bos_from_context() could race with ivpu_bo_free()
when prime buffer was closed after vpu device was closed.
Move the bo_list from context to vdev and use a dedicated lock to
sync it. This list is not modified when BO is added/removed from
a context.
From: Jacek Lawrynowicz
gem->open() is called during handle creation for a gem object.
It is called during prime import and in BO_CREATE ioctl.
Signed-off-by: Jacek Lawrynowicz
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_gem.c | 66 ---
Use GEM shmem for buffer management code
Jacek Lawrynowicz (4):
accel/ivpu: Allocate vpu_addr in gem->open() callback
accel/ivpu: Fix locking in ivpu_bo_remove_all_bos_from_context()
accel/ivpu: Remove support for uncached buffers
accel/ivpu: Use GEM shmem helper for all buffers
On Fri, Sep 01, 2023 at 11:59:16AM +0200, Michael Walle wrote:
> mtk_drm_find_possible_crtc_by_comp() assumed that the main path will
> always have the CRTC with id 0, the ext id 1 and the third id 2. This
> is only true if the paths are all available. But paths are optional (see
> also comment in
From: Pranjal Ramajor Asha Kanojiya
Since drm_dev_alloc() is deprecated it is recommended to use
devm_drm_dev_alloc() instead. Update the driver to start using
devm_drm_dev_alloc().
Signed-off-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Carl Vanderlip
Reviewed-by: Jeffrey Hugo
From: Pranjal Ramajor Asha Kanojiya
As qaic drivers base device is connected to host via PCI framework, it
makes sense to register in PCI framework at the beginning of module
init.
Signed-off-by: Pranjal Ramajor Asha Kanojiya
Reviewed-by: Carl Vanderlip
Reviewed-by: Jeffrey Hugo
On Wed, 9 Aug 2023 18:53:15 +0200
Boris Brezillon wrote:
> +/**
> + * DOC: MMIO regions exposed to userspace.
> + *
> + * .. c:macro:: DRM_PANTHOR_USER_MMIO_OFFSET
> + *
> + * File offset for all MMIO regions being exposed to userspace. Don't use
> + * this value directly, use
On Fri, Sep 1, 2023 at 6:00 PM Michael Walle wrote:
>
> Hi,
>
> >> I was just curious if you know of any development for that (or
> >> similar)
> >> in the kernel.
> >
> > This is probably because support for this SoC began with Chromebooks,
> > which have fixed and defined uses for the
On 9/1/2023 3:49 AM, Stanislaw Gruszka wrote:
Add additional ctx number to error messages on mmu context
initialization failures.
Looking at this for the first time, the "why" doesn't seem obvious.
Based on my understanding, I suggest -
"Identify the mmu context that failed to initialize in
On Fri, 01 Sep 2023, Jani Nikula wrote:
> The driver was originally added in commit fcfa0ddc18ed ("drm/bridge:
> Drivers for megachips-stdp-ge-b850v3-fw (LVDS-DP++)"). I tried to
> look up the discussion, but didn't find anyone questioning the EDID
> reading part.
>
> Why does it not use
On Fri, Sep 01, 2023 at 08:22:07AM -0600, Jeffrey Hugo wrote:
> On 9/1/2023 3:49 AM, Stanislaw Gruszka wrote:
> > ivpu_pm_init() does not return any error, make it void.
> >
> > Reviewed-by: Karol Wachowski
> > Signed-off-by: Stanislaw Gruszka
> > ---
> > drivers/accel/ivpu/ivpu_drv.c | 4
On 8/30/2023 11:20 PM, Evan Quan wrote:
To support the WBRF mechanism, Wifi adapters utilized in the system must
Since this is the first mention of WBRF in the core wireless code IMO
you should indicate what this is an acronym for and briefly describe it
(or add a lore link).
I'm wondering
Remove 'file' parameter from struct machdep_calls.phys_mem_access_prot
and its implementation in pci_phys_mem_access_prot(). The file is not
used on PowerPC. By removing it, a later patch can simplify fbdev's
mmap code, which uses phys_mem_access_prot() on PowerPC.
Signed-off-by: Thomas
Call __phys_mem_access_prot() from the fbdev mmap helper fb_pgprotect().
Allows us to avoid the file argument, which can then be removed from
fB_pgprotect() entirely. No other architecture uses the parameter.
Signed-off-by: Thomas Zimmermann
---
arch/powerpc/include/asm/fb.h | 6 +++---
1 file
Fix coding style. No functional changes.
Signed-off-by: Thomas Zimmermann
---
arch/powerpc/include/asm/machdep.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index
Rename the fbdev mmap helper fb_pgprotect() to fb_pgprot_device().
The helper sets VMA page-access flags for framebuffers in device I/O
memory. The new name follows pgprot_device(), which does the same for
arbitrary devices.
Also clean up the helper's parameters and return value. Instead of
the
Refactor fb_pgprotect() in PowerPC to work without struct file. Then
clean up and rename fb_pgprotect(). This change has been discussed at
[1] in the context of refactoring fbdev's mmap code.
The first three patches adapt PowerPC's internal interfaces to
provide a phys_mem_access_prot() that
On 9/1/2023 3:49 AM, Stanislaw Gruszka wrote:
ivpu_pm_init() does not return any error, make it void.
Reviewed-by: Karol Wachowski
Signed-off-by: Stanislaw Gruszka
---
drivers/accel/ivpu/ivpu_drv.c | 4 +---
drivers/accel/ivpu/ivpu_fw.c | 2 +-
drivers/accel/ivpu/ivpu_pm.c | 4 +---
The DP CTS test for EDID last block checksum expects the checksum for
the last block, invalid or not. Skip the validity check.
For the most part (*), the EDIDs returned by drm_get_edid() will be
valid anyway, and there's the CTS workaround to get the checksum for
completely invalid EDIDs. See
On 9/1/2023 3:49 AM, Stanislaw Gruszka wrote:
From: Jacek Lawrynowicz
Reduce the number of error messages per single failure in
ivpu_dev_init() and ivpu_probe().
Most error messages are already printed by functions called
from ivpu_dev_init(). Add missed error prints in ivpu_ipc_init()
and
On 17:01-20230901, Aradhya Bhatia wrote:
> On 01-Sep-23 15:01, Jai Luthra wrote:
> > Fix the NULL pointer dereference when no monitor is connected, and the
> > sound card is opened from userspace.
> >
> > Instead return an empty buffer (of zeroes) as the EDID i
On some i915 platforms at least the HPD poll work involves I2C
bit-banging using udelay()s to probe for monitor EDIDs. This in turn
may trigger the
workqueue: output_poll_execute [drm_kms_helper] hogged CPU for >1us 4
times, consider switching to WQ_UNBOUND
warning. Fix this by scheduling
Hi Boris,
On Wed, Aug 09, 2023 at 06:53:15PM +0200, Boris Brezillon wrote:
> Panthor follows the lead of other recently submitted drivers with
> ioctls allowing us to support modern Vulkan features, like sparse memory
> binding:
>
> - Pretty standard GEM management ioctls (BO_CREATE and
tests: Add tests for ttm_bo
functions
config: openrisc-allmodconfig
(https://download.01.org/0day-ci/archive/20230901/202309011935.bbpezbuq-...@intel.com/config)
compiler: or1k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20230901/20230901193
Hi,
On Fri, Sep 1, 2023 at 1:15 AM Maxime Ripard wrote:
>
> On Thu, Aug 31, 2023 at 11:18:49AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Aug 31, 2023 at 12:38 AM Maxime Ripard wrote:
> > >
> > > If so, then I think we can implement everything by doing something like:
> > >
> > > -
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 8e455145d8f163aefa6b9cc29478e0a9f82276e6
commit: 0b30d57acafcaa5374756d314ee54f80d0bcc860 [1/3] drm/debugfs: rework
debugfs directory creation v5
config: parisc-randconfig-r033-20230901
(https://download.01.org/0day-ci
Add tests for ttm_bo functions
config: openrisc-allmodconfig
(https://download.01.org/0day-ci/archive/20230901/202309011935.bbpezbuq-...@intel.com/config)
compiler: or1k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20230901/20230901193
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 8e455145d8f163aefa6b9cc29478e0a9f82276e6
commit: 0b30d57acafcaa5374756d314ee54f80d0bcc860 [1/3] drm/debugfs: rework
debugfs directory creation v5
config: arm-randconfig-r021-20230901
(https://download.01.org/0day-ci/archive
rnel.org/r/d914169aee773ee20c0b730b38d42a1fd7613bb6.1693479161.git.karolina.stolarek%40intel.com
patch subject: [PATCH 3/3] drm/ttm/tests: Add tests for ttm_bo functions
config: openrisc-allmodconfig
(https://download.01.org/0day-ci/archive/20230901/202309011935.bbpezbuq-...@intel.com/config)
compiler: or1k-linux-gcc (GCC) 13.2.0
reproduce (thi
On 01/09/2023 00:57, Jessica Zhang wrote:
As I participate more actively in the drm/panel subsystem, I would
like to get notified about new changes in this area.
Since I have contributed and continue to contribute to drm/panel,
add myself as a reviewer for the DRM panel drivers to help the
rnel.org/r/d914169aee773ee20c0b730b38d42a1fd7613bb6.1693479161.git.karolina.stolarek%40intel.com
patch subject: [PATCH 3/3] drm/ttm/tests: Add tests for ttm_bo functions
config: openrisc-allmodconfig
(https://download.01.org/0day-ci/archive/20230901/202309011935.bbpezbuq-...@intel.com/config)
compiler: or1k
On Thu, 31 Aug 2023, Alex Hung wrote:
> On 2023-08-30 01:29, Jani Nikula wrote:
>> On Tue, 29 Aug 2023, Alex Hung wrote:
>>> There is a patch under internal reviews. It removes calls edid_override
>>> and drm_edid_override_connector_update as intended in this patchset but
>>> does not remove the
Geert Uytterhoeven writes:
Hello Geert,
> Hi Maxime,
>
> On Fri, Sep 1, 2023 at 2:00 PM Maxime Ripard wrote:
>> On Fri, Sep 01, 2023 at 10:36:17AM +0200, Geert Uytterhoeven wrote:
>> > On Fri, Sep 1, 2023 at 10:22 AM Maxime Ripard wrote:
>> > > On Wed, Aug 30, 2023 at 08:25:08AM +0200, Javier
On Fri, Sep 01, 2023 at 07:59:21AM +0200, Thomas Hellström (Intel) wrote:
>
> On 8/31/23 21:07, Danilo Krummrich wrote:
> > On Thu, Aug 31, 2023 at 06:53:01PM +0200, Thomas Hellström (Intel) wrote:
> > > Hi,
> > >
> > > On 8/31/23 13:18, Danilo Krummrich wrote:
> > > > On Thu, Aug 31, 2023 at
Hi Maxime,
On Fri, Sep 1, 2023 at 2:00 PM Maxime Ripard wrote:
> On Fri, Sep 01, 2023 at 10:36:17AM +0200, Geert Uytterhoeven wrote:
> > On Fri, Sep 1, 2023 at 10:22 AM Maxime Ripard wrote:
> > > On Wed, Aug 30, 2023 at 08:25:08AM +0200, Javier Martinez Canillas wrote:
> > > > The commit
/tests: Add tests for ttm_bo functions
config: openrisc-allmodconfig
(https://download.01.org/0day-ci/archive/20230901/202309011935.bbpezbuq-...@intel.com/config)
compiler: or1k-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20230901/202309011935
On Fri, Sep 01, 2023 at 10:36:17AM +0200, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Fri, Sep 1, 2023 at 10:22 AM Maxime Ripard wrote:
> > On Wed, Aug 30, 2023 at 08:25:08AM +0200, Javier Martinez Canillas wrote:
> > > The commit 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's
> >
From: Mikko Perttunen
UBSAN reports an invalid load for bool, as the iosys_map is read
later without being initialized. Zero-initialize it to avoid this.
Reported-by: Ashish Mhetre
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/gem.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Johnny Liu
Original implementation over allocates the memory size for the
contexts list. The size of memory for the contexts list is based
on the number of iommu groups specified in the device tree.
Fixes: 8aa5bcb61612 ("gpu: host1x: Add context device management code")
Signed-off-by:
Hi All,
Gentle ping. This patch[1] is posted around 2 months now.
Please let me know is there any dependency/blockers for
accepting this patch series?
https://lore.kernel.org/all/20230704090447.27420-1-biju.das...@bp.renesas.com/
Cheers,
Biju
> -Original Message-
> From: Biju Das
>
1 - 100 of 153 matches
Mail list logo
