On Thu, Aug 10, 2023 at 2:15 AM Jason-JH.Lin wrote:
>
> Add DSI as a main display output selection on MT8188 VDOSYS0.
>
> Signed-off-by: Nathan Lu
> Reviewed-by: Matthias Brugger
> Signed-off-by: Jason-JH.Lin
Reviewed-by: Fei Shao
Tested-by: Fei Shao
On Thu, Aug 10, 2023 at 2:16 AM Jason-JH.Lin wrote:
>
> Add implementation of mtk_dsi_encoder_index to mtk_ddp_comp_func
> to make mtk_dsi support dynamic connector selection.
>
> Signed-off-by: Jason-JH.Lin
Reviewed-by: Fei Shao
Tested-by: Fei Shao
On Thu, Aug 10, 2023 at 2:16 AM Jason-JH.Lin wrote:
>
> Add dynamic select available connector flow in mtk_drm_crtc_create()
> and mtk_drm_crtc_atomic_enable().
>
> In mtk_drm_crtc_create(), if there is a connector routes array in drm
> driver data, all components definded in the connector routes
On Thu, Aug 10, 2023 at 2:15 AM Jason-JH.Lin wrote:
>
> To support dynamic connector selection function, each ddp_comp need to
> get their encoder_index to identify which connector should be selected.
>
> Add encoder_index function to mtk_ddp_comp_funcs and the implementation
> of
On Thu, Aug 10, 2023 at 2:15 AM Jason-JH.Lin wrote:
>
> According to mtk_drm_kms_init(), the all_drm_private array in each
> drm private data stores all drm private data in display path order.
>
> In mtk_drm_get_all_drm_priv(), each element in all_drm_priv should have one
> display path private
On Thu, Aug 10, 2023 at 2:15 AM Jason-JH.Lin wrote:
>
> Add mtk_drm_crtc_path enum for each display path.
>
> Instead of using array index of all_drm_priv in mtk_drm_kms_init(),
> mtk_drm_crtc_path enum can make code more readable.
>
> Signed-off-by: Jason-JH.Lin
Tested with MT8188 and the
On Thu, Aug 10, 2023 at 2:35 AM Jason-JH.Lin wrote:
>
> Add missing mmsys_dev_num to mt8188 vdosys0 driver data.
>
> Fixes: 54b48080278a ("drm/mediatek: Add mediatek-drm of vdosys0 support for
> mt8188")
> Signed-off-by: Jason-JH.Lin
> Reviewed-by: CK Hu
> Reviewed-by: AngeloGioacchino Del
: 6995e2de6891c724bfeb2db33d7b87775f913ad1
patch link:
https://lore.kernel.org/r/20230809192514.158062-2-jfalempe%40redhat.com
patch subject: [PATCH 1/2] drm/panic: Add a drm panic handler
config: nios2-randconfig-r011-20230809
(https://download.01.org/0day-ci/archive/20230810/202308101307.hbeyaamn-...@intel.com/config
On Thu, Aug 10, 2023 at 12:17:23AM +0200, Danilo Krummrich wrote:
> With the current mental model every GPU scheduler instance represents
> a single HW ring, while every entity represents a software queue feeding
> into one or multiple GPU scheduler instances and hence into one or
> multiple HW
On 10.08.23 05:03, Bagas Sanjaya wrote:
>
> I notice a regression report on Bugzilla [1]. Quoting from it:
>
>> Kernel 6.4.6 compiled from source worked AOK on my desktop with Intel Xeon
>> cpu and Nvidia graphics - see below for system specs.
>>
>> Kernels 6.4.7 & 6.4.8 also compiled from
On Wed, 2023-08-02 at 16:35 -0700, Teres Alexis, Alan Previn wrote:
> If we are at the end of suspend or very early in resume
> its possible an async fence signal could lead us to the
> execution of the context destruction worker (after the
> prior worker flush).
>
alan:snip
>
> static void
On Wednesday, August 9, 2023 9:54 PM Ulf Hansson wrote:
>
> On Mon, 7 Aug 2023 at 08:06, Liu Ying wrote:
> >
> > Add the device link when panel bridge is attached and delete the link
> > when panel bridge is detached. The drm device is the consumer while
> > the panel device is the supplier.
Hi,
I notice a regression report on Bugzilla [1]. Quoting from it:
> Kernel 6.4.6 compiled from source worked AOK on my desktop with Intel Xeon
> cpu and Nvidia graphics - see below for system specs.
>
> Kernels 6.4.7 & 6.4.8 also compiled from source with identical configs hang
> with a
In tcp_recvmsg_locked(), detect if the skb being received by the user
is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
flag - pass it to tcp_recvmsg_devmem() for custom handling.
tcp_recvmsg_devmem() copies any data in the skb header to the linear
buffer, and returns a
ncdevmem is a devmem TCP netcat. It works similarly to netcat, but it
sends and receives data using the devmem TCP APIs. It uses udmabuf as
the dmabuf provider. It is compatible with a regular netcat running on
a peer, or a ncdevmem running on a peer.
In addition to normal netcat support,
For device memory TCP, we expect the skb headers to be available in host
memory for access, and we expect the skb frags to be in device memory
and unaccessible to the host. We expect there to be no mixing and
matching of device memory frags (unaccessible) with host memory frags
(accessible) in the
Add an interface for the user to notify the kernel that it is done
reading the NET_RX dmabuf pages returned as cmsg. The kernel will
drop the reference on the NET_RX pages to make them available for
re-use.
Signed-off-by: Willem de Bruijn
Signed-off-by: Kaiyuan Zhang
Signed-off-by: Mina
Make skb_frag_page() fail in the case where the frag is not backed
by a page, and fix its relevent callers to handle this case.
Correctly handle skb_frag refcounting in the page_pool_iovs case.
Signed-off-by: Mina Almasry
---
include/linux/skbuff.h | 40 +---
Overload the LSB of struct page* to indicate that it's a page_pool_iov.
Refactor mm calls on struct page * into helpers, and add page_pool_iov
handling on those helpers. Modify callers of these mm APIs with calls to
these helpers instead.
In areas where struct page* is dereferenced, add a check
Implement a memory provider that allocates dmabuf devmem page_pool_iovs.
Support of PP_FLAG_DMA_MAP, PP_FLAG_DMA_SYNC_DEV, and PP_FLAG_PAGE_FRAG
is omitted. PP_FLAG_DMA_MAP is irrelevant as dma-buf devmem is already
mapped. The other flags are omitted for simplicity.
The provider receives a
Implement a few updates to Jakub's RFC memory provider[1] API to make it
suitable for device memory TCP:
1. Currently for devmem TCP the driver's netdev_rx_queue holds a
reference to the netdev_dmabuf_binding struct and needs to pass that to
the page_pool's memory provider somehow. For PoC
API takes the dma-buf fd as input, and binds it to the netdevice. The
user can specify the rx queue to bind the dma-buf to. The user should be
able to bind the same dma-buf to multiple queues, but that is left as
a (minor) TODO in this iteration.
Suggested-by: Stanislav Fomichev
Signed-off-by:
Implement netdev devmem allocator. The allocator takes a given struct
netdev_dmabuf_binding as input and allocates page_pool_iov from that
binding.
The allocation simply delegates to the binding's genpool for the
allocation logic and wraps the returned memory region in a page_pool_iov
struct.
Add a netdev_dmabuf_binding struct which represents the
dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
an rx queue on the netdevice. On the binding, the dma_buf_attach
& dma_buf_map_attachment will occur. The entries in the sg_table from
mapping will be inserted into a
Changes in RFC v2:
--
The sticking point in RFC v1[1] was the dma-buf pages approach we used to
deliver the device memory to the TCP stack. RFC v2 is a proof-of-concept
that attempts to resolve this by implementing scatterlist support in the
networking stack, such that we can
On Wed, Aug 9, 2023 at 8:04 AM Pintu Agarwal wrote:
>
> Hi,
>
> On Thu, 3 Aug 2023 at 23:04, Pintu Agarwal wrote:
> >
> > Hi,
> >
> > On Wed, 2 Aug 2023 at 15:17, Christoph Hellwig wrote:
> > >
> > > On Tue, Aug 01, 2023 at 10:39:04PM -0700, John Stultz wrote:
> > > > So, forgive me, I've not
drm_exec_prepare_obj() and drm_exec_prepare_array() both reserve
dma-fence slots and hence a dma_resv_list without ever freeing it.
Make sure to call drm_gem_private_object_fini() for each GEM object
passed to drm_exec_prepare_obj()/drm_exec_prepare_array() throughout the
test to fix this up.
On 8/8/23 09:21, Boris Brezillon wrote:
On Thu, 3 Aug 2023 18:52:20 +0200
Danilo Krummrich wrote:
When no custom lock is set to protect a GEMs GPUVA list, lockdep checks
should fall back to the GEM objects dma-resv lock. With the current
implementation we're setting the lock_dep_map of the
With the current mental model every GPU scheduler instance represents
a single HW ring, while every entity represents a software queue feeding
into one or multiple GPU scheduler instances and hence into one or
multiple HW rings.
This does not really scale with firmware schedulers feeding the
On Tue, Aug 8, 2023 at 2:03 PM Konrad Dybcio wrote:
>
> A7xx GMUs can be slow as molasses at times.
> Increase the timeout to 1 second to match the vendor driver.
>
> Tested-by: Neil Armstrong # on SM8550-QRD
> Tested-by: Dmitry Baryshkov # sm8450
> Signed-off-by: Konrad Dybcio
> ---
>
Applied. Thanks!
Alex
On Mon, Jul 3, 2023 at 7:16 PM Uros Bizjak wrote:
>
> Use local64_try_cmpxchg instead of local64_cmpxchg (*ptr, old, new) == old
> in amdgpu_perf_read. x86 CMPXCHG instruction returns success in ZF flag,
> so this change saves a compare after cmpxchg (and related move
On Tue, Aug 8, 2023 at 2:02 PM Konrad Dybcio wrote:
>
> This series attempts to introduce Adreno 700 support (with A730 and A740
> found on SM8450 and SM8550 respectively), reusing much of the existing
> A6xx code. This submission largely lays the groundwork for expansion and
> more or less gives
Thanks Rodrigo for reviewing this.
On Mon, 2023-08-07 at 13:52 -0400, Vivi, Rodrigo wrote:
> On Wed, Aug 02, 2023 at 04:34:59PM -0700, Alan Previn wrote:
> > Suspend is not like reset, it can unroll, so we have to properly
> > flush pending context-guc-id deregistrations to complete before
> > we
On Wed, Aug 9, 2023 at 10:53 AM Boris Brezillon
wrote:
>
> Hello,
>
> This is the second version of the kernel driver meant to support new Mali
> GPUs which are delegating the scheduling to a firmware.
>
> The RFC has been dropped as the major blocking points have been addressed
> (request to use
On 05/08/23 10:26, Maira Canal wrote:
> On 7/21/23 15:23, Arthur Grillo wrote:
>> Insert parameterized test for the drm_fb_memcpy() to ensure correctness
>> and prevent future regressions. The test case can accept different
>> formats.
>>
>> Signed-off-by: Arthur Grillo
>> ---
>>
Thanks Rodrigo for reviewing this.
On Mon, 2023-08-07 at 13:56 -0400, Vivi, Rodrigo wrote:
> On Wed, Aug 02, 2023 at 04:35:01PM -0700, Alan Previn wrote:
> > When suspending, add a timeout when calling
> > intel_gt_pm_wait_for_idle else if we have a lost
> > G2H event that holds a wakeref (which
This module displays a user friendly message when a kernel panic
occurs. It currently doesn't contain any debug information,
but that can be added later.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/Kconfig | 11 ++
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_drv.c |
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/tiny/simpledrm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c
This introduces a new drm panic handler, which displays a message when a panic
occurs.
So when fbcon is disabled, you can still see a kernel panic.
This is one of the missing feature, when disabling VT/fbcon in the kernel:
https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/
Fbcon
On Wed, Aug 9, 2023 at 3:35 AM Michel Dänzer wrote:
>
> On 8/8/23 19:03, Marek Olšák wrote:
> > It's the same situation as SIGSEGV. A process can catch the signal,
> > but if it doesn't, it gets killed. GL and Vulkan APIs give you a way
> > to catch the GPU error and prevent the process
On Wed, Aug 9, 2023 at 8:28 PM Karol Herbst wrote:
>
> On Wed, Aug 9, 2023 at 4:04 PM Thorsten Leemhuis
> wrote:
> >
> > On 09.08.23 15:13, Takashi Iwai wrote:
> > >
> > > If this can't be fixed quickly, I suppose it's safer to revert it from
> > > 6.4.y for now. 6.5 is still being cooked, but
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 21ef7b1e17d039053edaeaf41142423810572741 Add linux-next specific
files for 20230809
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202307251531.p8zlftmz-...@intel.com
https
On Wed, Aug 9, 2023 at 4:04 PM Thorsten Leemhuis
wrote:
>
> On 09.08.23 15:13, Takashi Iwai wrote:
> >
> > If this can't be fixed quickly, I suppose it's safer to revert it from
> > 6.4.y for now. 6.5 is still being cooked, but 6.4.x is already in
> > wide deployment, hence the regression has to
Hi Dave, Daniel,
Fixes for 6.5. Was on PTO last week, so two weeks worth.
The following changes since commit 52a93d39b17dc7eb98b6aa3edb93943248e03b2f:
Linux 6.5-rc5 (2023-08-06 15:07:51 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
On 8/7/2023 8:43 AM, Dan Carpenter wrote:
On Mon, Aug 07, 2023 at 05:09:34PM +0300, Dan Carpenter wrote:
The encode_dma() function has some validation on in_trans->size but it's
not complete and it would be more clear to move those checks to
find_and_map_user_pages().
The encode_dma() had two
To support dynamic connector selection function, each ddp_comp need to
get their encoder_index to identify which connector should be selected.
Add encoder_index function to mtk_ddp_comp_funcs and the implementation
of mtk_dpi_encoder_index to get its encoder_index.
Signed-off-by: Jason-JH.Lin
Add missing mmsys_dev_num to mt8188 vdosys0 driver data.
Fixes: 54b48080278a ("drm/mediatek: Add mediatek-drm of vdosys0 support for
mt8188")
Signed-off-by: Jason-JH.Lin
Reviewed-by: CK Hu
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file
Add mtk_drm_crtc_path enum for each display path.
Instead of using array index of all_drm_priv in mtk_drm_kms_init(),
mtk_drm_crtc_path enum can make code more readable.
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 +++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h |
To support DSI and eDP as main display connector without modifying
mtk-drm driver, we add connector dynamic selection capability.
Change in v9:
1. change subject title and [PATCH v9 5/7] title.
2. separate [PATCH v8 4/8] to 2 parts and merge them into [PATCH v9 4/7]
and [PATCH v9 5/7].
3. fix
Add DSI as a main display output selection on MT8188 VDOSYS0.
Signed-off-by: Nathan Lu
Reviewed-by: Matthias Brugger
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
Add implementation of mtk_dsi_encoder_index to mtk_ddp_comp_func
to make mtk_dsi support dynamic connector selection.
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
drivers/gpu/drm/mediatek/mtk_dsi.c
According to mtk_drm_kms_init(), the all_drm_private array in each
drm private data stores all drm private data in display path order.
In mtk_drm_get_all_drm_priv(), each element in all_drm_priv should have one
display path private data, such as:
all_drm_priv[CRTC_MAIN] should only have main_path
Add dynamic select available connector flow in mtk_drm_crtc_create()
and mtk_drm_crtc_atomic_enable().
In mtk_drm_crtc_create(), if there is a connector routes array in drm
driver data, all components definded in the connector routes array will
be checked and their encoder_index will be set.
In
Add an entry for the Panthor driver to the MAINTAINERS file.
v2:
- New commit
Signed-off-by: Boris Brezillon
---
If anyone from Arm wants to volunteer to become a co-maintainer, that
would be highly appreciated
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git
From: Liviu Dudau
Arm has introduced a new v10 GPU architecture that replaces the Job Manager
interface with a new Command Stream Frontend. It adds firmware driven
command stream queues that can be used by kernel and user space to submit
jobs to the GPU.
Add the initial schema for the device
This is the last piece missing to expose the driver to the outside
world.
This is basically a wrapper between the ioctls and the other logical
blocks.
v2:
- Rename the driver (pancsf -> panthor)
- Change the license (GPL2 -> MIT + GPL2)
- Split the driver addition commit
- Document the code
-
Anything relating to GEM object management is placed here. Nothing
particularly interesting here, given the implementation is based on
drm_gem_shmem_object, which is doing most of the work.
v2:
- Rename the driver (pancsf -> panthor)
- Change the license (GPL2 -> MIT + GPL2)
- Split the driver
Now that all blocks are available, we can add/update Kconfig/Makefile
files to allow compilation.
v2:
- Rename the driver (pancsf -> panthor)
- Change the license (GPL2 -> MIT + GPL2)
- Split the driver addition commit
- Add new dependencies on GPUVA and DRM_SCHED
Signed-off-by: Boris Brezillon
Contains everything that's FW related, that includes the code dealing
with the microcontroller unit (MCU) that's running the FW, and anything
related to allocating memory shared between the FW and the CPU.
A few global FW events are processed in the IRQ handler, the rest is
forwarded to the
This is the piece of software interacting with the FW scheduler, and
taking care of some scheduling aspects when the FW comes short of slots
scheduling slots. Indeed, the FW only expose a few slots, and the kernel
has to give all submission contexts, a chance to execute their jobs.
The
Handles everything that's not related to the FW, the MMU or the
scheduler. This is the block dealing with the GPU property retrieval,
the GPU block power on/off logic, and some global operations, like
global cache flushing.
v2:
- Rename the driver (pancsf -> panthor)
- Change the license (GPL2 ->
Tiler heap growing requires some kernel driver involvement: when the
tiler runs out of heap memory, it will raise an exception which is
either directly handled by the firmware if some free heap chunks are
available in the heap context, or passed back to the kernel otherwise.
The heap helpers will
The panthor driver is designed in a modular way, where each logical
block is dealing with a specific HW-block or software feature. In order
for those blocks to communicate with each other, we need a central
panthor_device collecting all the blocks, and exposing some common
features, like interrupt
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 BO_MMAP_OFFSET),
with the 'exclusive-VM' bit to speed-up BO reservation on job submission
-
MMU and VM management is related and placed in the same source file.
Page table updates are delegated to the io-pgtable-arm driver that's in
the iommu subsystem.
The VM management logic is based on drm_gpuva_mgr, and is assuming the
VA space is mostly managed by the usermode driver, except for a
Every thing related to devfreq in placed in panthor_devfreq.c, and
helpers that can be called by other logical blocks are exposed through
panthor_devfreq.h.
This implementation is loosely based on the panfrost implementation,
the only difference being that we don't count device users, because
the
Those are the registers directly accessible through the MMIO range.
FW registers are exposed in panthor_fw.h.
v2:
- Rename the driver (pancsf -> panthor)
- Change the license (GPL2 -> MIT + GPL2)
- Split the driver addition commit
Signed-off-by: Boris Brezillon
---
This way we can grab a pages ref without acquiring the resv lock when
pages_use_count > 0. Need to implement asynchronous map using the
drm_gpuva_mgr when the map/unmap operation triggers a mapping split,
requiring the new left/right regions to grab an additional page ref
to guarantee that the
Hello,
This is the second version of the kernel driver meant to support new Mali
GPUs which are delegating the scheduling to a firmware.
The RFC has been dropped as the major blocking points have been addressed
(request to use drm_sched, request to implement a VM_BIND-like ioctl,
request to use
On Wed, Aug 09, 2023 at 01:42:16PM +0200, Artur Weber wrote:
> Fixes the following warning:
>
> drivers/video/backlight/lp855x_bl.c:252:7: warning: variable 'ret' is used
> uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
>
> Signed-off-by: Artur Weber
> Fixes:
Looks good to me.
Maybe the IN_FORMATS prop docs is a better place for this?
Em 21/07/2023 15:23, Arthur Grillo escreveu:
The drm_fb_memcpy() supports multi-plane formats. To fully test it in
the future, add multi-plane support to the conversion_buf_size() helper.
Signed-off-by: Arthur Grillo
---
I think this would be a more concrect improvement if the plane
On Wed, 09 Aug 2023 16:46:38 +0200,
Takashi Iwai wrote:
>
> On Wed, 09 Aug 2023 15:13:23 +0200,
> Takashi Iwai wrote:
> >
> > On Wed, 09 Aug 2023 14:19:23 +0200,
> > Karol Herbst wrote:
> > >
> > > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote:
> > > >
> > > > On Wed, 09 Aug 2023 13:42:09
Em 21/07/2023 15:23, Arthur Grillo escreveu:
Insert parameterized test for the drm_fb_build_fourcc_list() to ensure
correctness and prevent future regressions.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 143 ++
1 file changed, 143
From: Chris Morgan
Add support for the Anbernic 351V. Just like the 353 series the
underlying vendor is unknown/unmarked (at least not visible in a
non-destructive manner). The panel had slightly different init
sequences and timings in the BSP kernel, but works fine with the
same ones used in
From: Chris Morgan
Add support for the Anbernic RG351V panel. This panel is mostly
identical to the one used in the 353 series, except it has a different
panel ID when queried (0x4000 for the 351V, 0x3052 for the 353 panel)
and will not work without the inclusion of the
From: Chris Morgan
Document the Anbernic RG351V panel, which appears to be identical to
the panel used in their 353 series except for in inclusion of an
additional DSI format flag.
Signed-off-by: Chris Morgan
---
.../display/panel/newvision,nv3051d.yaml | 18 ++
1 file
Hi Christian,
Can this be applied to drm-misc? Other drivers are starting to make use
of this API and our builds with clang-17 and clang-18 have been broken
for some time due to this.
Cheers,
Nathan
On Mon, Jul 31, 2023 at 02:36:24PM +0200, Christian König wrote:
> GCC forbids to jump to labels
Em 21/07/2023 15:23, Arthur Grillo escreveu:
Insert parameterized test for the drm_fb_clip_offset() to ensure
correctness and prevent future regressions.
Signed-off-by: Arthur Grillo
---
.../gpu/drm/tests/drm_format_helper_test.c| 91 +++
1 file changed, 91 insertions(+)
On 8/9/23 16:56, Marek Szyprowski wrote:
Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
doesn't report empty level of packer header FIFO. In case of those SoCs,
use the old way of waiting for empty command tranfsfer FIFO, removed
recently by commit 14806c641582 ("Drain
Em 21/07/2023 15:23, Arthur Grillo escreveu:
Insert parameterized test for the drm_fb_swab() to ensure correctness
and prevent future regressions.
Signed-off-by: Arthur Grillo
---
[...]
+ .dst_pitch = TEST_USE_DEFAULT_PITCH,
+ .expected = {
+
Samsung DSIM used in older Exynos SoCs (like Exynos 4210, 4x12, 3250)
doesn't report empty level of packer header FIFO. In case of those SoCs,
use the old way of waiting for empty command tranfsfer FIFO, removed
recently by commit 14806c641582 ("Drain command transfer FIFO before
transfer").
Hi,
Em 21/07/2023 15:23, Arthur Grillo escreveu:
Test the default pitch fallback when NULL is passed as the dst_pitch on
the conversion procedures.
Signed-off-by: Arthur Grillo
---
With Maíra's comment about the duplicated drm_fb_xrgb_to_rgb565()
addressed:
Reviewed-by: André Almeida
On Wed, 09 Aug 2023 15:13:23 +0200,
Takashi Iwai wrote:
>
> On Wed, 09 Aug 2023 14:19:23 +0200,
> Karol Herbst wrote:
> >
> > On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote:
> > >
> > > On Wed, 09 Aug 2023 13:42:09 +0200,
> > > Karol Herbst wrote:
> > > >
> > > > On Wed, Aug 9, 2023 at 11:22
On Tue, Aug 08, 2023 at 04:14:55PM +0200, Christian König wrote:
> Am 08.08.23 um 16:06 schrieb Matthew Brost:
> > [SNIP]
> > > Basically workqueues are the in kernel infrastructure for exactly that use
> > > case and we are trying to re-create that here and that is usually a rather
> > > bad
On 09.08.23 15:13, Takashi Iwai wrote:
>
> If this can't be fixed quickly, I suppose it's safer to revert it from
> 6.4.y for now. 6.5 is still being cooked, but 6.4.x is already in
> wide deployment, hence the regression has to be addressed quickly.
Good luck with that. To quote
On 8/9/2023 5:24 AM, Stanislaw Gruszka wrote:
Hi
On Tue, Aug 08, 2023 at 06:45:51PM -0600, Jeffrey Hugo wrote:
On 8/8/2023 2:52 AM, Stanislaw Gruszka wrote:
On Thu, Aug 03, 2023 at 10:37:37AM +0200, Stanislaw Gruszka wrote:
Seems like we might want to decide this now, because if we define a
Commit cd3a8a596214 ("drm/ttm: remove ttm_bo_(un)lock_delayed_workqueue")
removed the implementations but not the declarations.
Signed-off-by: Yue Haibing
---
include/drm/ttm/ttm_bo.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
index
On Mon, 7 Aug 2023 at 08:06, Liu Ying wrote:
>
> Add the device link when panel bridge is attached and delete the link
> when panel bridge is detached. The drm device is the consumer while
> the panel device is the supplier. This makes sure that the drm device
> suspends eariler and resumes
Hi,
Instead of requiring each driver to care for assigning the owner member
of struct pwm_ops, handle that implicitly using a macro. Note that the
owner member has to be moved to struct pwm_chip, as the ops structure
usually lives in read-only memory and so cannot be modified.
The upside is
On Tue, 8 Aug 2023 11:44:05 +0100, Daniel Stone wrote:
> Userspace should not be able to trigger DRM_ERROR messages to spam the
> logs; especially not through atomic commit parameters which are
> completely legitimate for userspace to attempt.
>
>
Applied, thanks!
[1/1] drm/rockchip: Don't
Hi Jiapeng,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on next-20230809]
[cannot apply to linus/master v6.5-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Wed, 09 Aug 2023 14:19:23 +0200,
Karol Herbst wrote:
>
> On Wed, Aug 9, 2023 at 1:46 PM Takashi Iwai wrote:
> >
> > On Wed, 09 Aug 2023 13:42:09 +0200,
> > Karol Herbst wrote:
> > >
> > > On Wed, Aug 9, 2023 at 11:22 AM Takashi Iwai wrote:
> > > >
> > > > On Tue, 08 Aug 2023 12:39:32 +0200,
Applied. Thanks!
On Wed, Aug 9, 2023 at 2:15 AM Christian König wrote:
>
> Am 09.08.23 um 05:44 schrieb Ruan Jinjie:
> > The NULL initialization of the pointers assigned by kzalloc() first is
> > not necessary, because if the kzalloc() failed, the pointers will be
> > assigned NULL, otherwise
Applied. Thanks!
On Tue, Aug 8, 2023 at 7:26 PM Randy Dunlap wrote:
>
> These functions don't use kernel-doc notation for comments so
> don't begin each comment block with the "/**" kernel-doc marker.
>
> This prevents a bunch of kernel-doc warnings:
>
> dmub_replay.c:37: warning: This comment
The difference between drm_atomic_helper_commit_tail() and
drm_atomic_helper_commit_tail_rpm() is
drm_atomic_helper_commit_tail() will commit plane first and
then enable crtc, drm_atomic_helper_commit_tail_rpm() will
enable crtc first and then commit plane.
Before mediatek-drm enables crtc, the
Fix some IGT tests fail at iommu fault in OVL cursor plane.
Change in v5:
1. Rollback the entire series to v3.
2. Add more commit message inyo [PATCH v5 2/2].
Change in RESEND v4 :
1. Remove redundant plane_state assigning.
Change in v4:
1. Change disable all layer method to update
According to the comment in drm_atomic_helper_async_commit(),
we should make sure FBs have been swapped, so that cleanups in the
new_state performs a cleanup in the old FB.
So we should move swapping FBs after calling mtk_plane_update_new_state(),
to avoid using the old FB which could be freed.
Am Freitag, 4. August 2023, 16:27:06 CEST schrieb Uwe Kleine-König:
> Instead of requiring each driver to care for assigning the owner member
> of struct pwm_ops, handle that implicitly using a macro. Note that the
> owner member has to be moved to struct pwm_chip, as the ops structure
> usually
On 09/08/23 00:44, Ruan Jinjie wrote:
> The NULL initialization of the pointers assigned by
> kunit_kzalloc() first is not necessary, because if kunit_kzalloc()
> failed, the pointers will be assigned NULL, otherwise it works
> as usual. so remove it.
>
> Signed-off-by: Ruan Jinjie
> ---
>
1 - 100 of 112 matches
Mail list logo
