On Wed, 2024-06-12 at 15:42 -0500, Bjorn Helgaas wrote:
> On Wed, Jun 12, 2024 at 10:51:40AM +0200, Philipp Stanner wrote:
> > On Tue, 2024-06-11 at 16:44 -0500, Bjorn Helgaas wrote:
> > > I'm trying to merge these into pci/next, but I'm having a hard
> > > time
> > > writing the merge commit log.
PREEMPT_RT has a different locking implementation for ww_mutex. The
base mutex of struct ww_mutex is declared as struct WW_MUTEX_BASE. The
latter is defined as `mutex' for non-PREEMPT_RT builds and `rt_mutex'
for PREEMPT_RT builds.
Using mutex_lock() directly on the base mutex in
ttm_bo_reserve_de
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger any
issue:
Reported-and-tested-by: syzbot+40c7dad27267f6183...@syzkaller.appspotmail.com
Tested on:
commit: c7db1220 fixup! udmabuf: pin the pages using memfd_pin..
git tree: https://gitlab.freedesktop
>
> HEAD commit:9d99040b1bc8 Add linux-next specific files for 20240529
> git tree: linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=14c083e698
> kernel config: https://syzkaller.appspot.com/x/.config?x=735e953fee00ec19
> dashboard link:
> https://syzkaller.app
+amd-gfx
On Thu, Jun 13, 2024 at 1:59 AM Marek Olšák wrote:
>
> Hi Thomas,
>
> Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
> breaks (crashes?) lightdm (login screen) such that all I get is the
> terminal. It's also reproducible with tag v6.9 where the commit is
> present.
>
>
Hi Thomas,
Commit 9eac534db0013aff9b9124985dab114600df9081 as per the title
breaks (crashes?) lightdm (login screen) such that all I get is the
terminal. It's also reproducible with tag v6.9 where the commit is
present.
Reverting the commit fixes lightdm. A workaround is to bypass lightdm
by trig
If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.
When creating the initial framebuffer configuration detect the
lid status and if it's closed disable any eDP connectors.
Also set up a workqueue to monit
Address following issues regarding CMRR
1. Describe target_rr_divider in struct drm_dp_as_sdp.
3. Use required macro to avoid overflow.
Mitul Golani (2):
drm/dp: Describe target_rr_divider in struct drm_dp_as_sdp
drm/i915/display: Update calculation to avoid overflow
drivers/gpu/drm/i915/di
Update calculation to avoid overflow.
Fixes: 1676ecd303ac ("drm/i915: Compute CMRR and calculate vtotal")
Cc: Mitul Golani
Cc: Ankit Nautiyal
Cc: Suraj Kandpal
Cc: Jani Nikula
Cc: Stephen Rothwell
Signed-off-by: Mitul Golani
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/int
Describe newly added parameter target_rr_divider in struct
drm_dp_as_sdp.
Fixes: a20c6d954d75 ("drm/dp: Add refresh rate divider to struct representing
AS SDP")
Cc: Mitul Golani
Cc: Arun R Murthy
Cc: Suraj Kandpal
Cc: Ankit Nautiyal
Cc: Jani Nikula
Cc: Stephen Rothwell
Signed-off-by: Mitul
Buffer driver");
MODULE_LICENSE("GPL");
#endif /* MODULE */
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-vfb-a4ed3808e861
Hi Tomeu,
kernel test robot noticed the following build errors:
[auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670]
url:
https://github.com/intel-lab-lkp/linux/commits/Tomeu-Vizoso/iommu-rockchip-Add-compatible-for-rockchip-rk3588-iommu/20240612-215814
base
On 28/05/2024 03:13, Dmitry Baryshkov wrote:
> Bindings please. Also, note that per the datasheet the bridge uses two
> supplies, Vcc for 3.3V and Vdd for 1.1V, so it doesn't fully fit the
> simple-bridge.c (which might need to be adjusted for the second supply).
> Chapter 7.3.2 of the datasheet p
Hi Tomeu,
kernel test robot noticed the following build errors:
[auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670]
url:
https://github.com/intel-lab-lkp/linux/commits/Tomeu-Vizoso/iommu-rockchip-Add-compatible-for-rockchip-rk3588-iommu/20240612-215814
base
On 12/06/2024 19:44, Vinod Koul wrote:
> On 06-06-24, 18:07, Marc Gonzalez wrote:
>
>> HDMI TX block embedded in the APQ8098.
>
> This one too
I assume this refers to:
"Why is the patch titled display/msm, this is phy patch and it should be
tagged as such."
I always copy what others have done b
fo *info,
}
EXPORT_SYMBOL(mac_find_mode);
+MODULE_DESCRIPTION("MacOS video mode library");
MODULE_LICENSE("GPL");
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-macmodes-7a15b2b20b12
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 cmsg
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, ncdevmem
Add documentation outlining the usage and details of devmem TCP.
Signed-off-by: Mina Almasry
Reviewed-by: Bagas Sanjaya
---
v9:
https://lore.kernel.org/netdev/20240403002053.2376017-14-almasrym...@google.com/
- Bagas doc suggestions.
v8:
- Applied docs suggestions (Randy). Thanks!
v7:
- App
Implement a memory provider that allocates dmabuf devmem in the form of
net_iov.
The provider receives a reference to the struct netdev_dmabuf_binding
via the pool->mp_priv pointer. The driver needs to set this pointer for
the provider in the net_iov.
The provider obtains a reference on the netde
Convert netmem to be a union of struct page and struct netmem. Overload
the LSB of struct netmem* to indicate that it's a net_iov, otherwise
it's a page.
Currently these entries in struct page are rented by the page_pool and
used exclusively by the net stack:
struct {
unsigned long pp_mag
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 a netdev_dmabuf_binding struct which represents the
dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
rx queues 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 genpool
Add an interface for the user to notify the kernel that it is done
reading the devmem dmabuf frags returned as cmsg. The kernel will
drop the reference on the frags to make them available for reuse.
Signed-off-by: Willem de Bruijn
Signed-off-by: Kaiyuan Zhang
Signed-off-by: Mina Almasry
---
v
Make skb_frag_page() fail in the case where the frag is not backed
by a page, and fix its relevant callers to handle this case.
Signed-off-by: Mina Almasry
---
v10:
- Fixed newly generated kdoc warnings found by patchwork. While we're
at it, fix the Return section of the functions I touched.
Implement netdev devmem allocator. The allocator takes a given struct
netdev_dmabuf_binding as input and allocates net_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 net_iov
struct.
Signed-off-by:
Abstrace the memory type from the page_pool so we can later add support
for new memory types. Convert the page_pool to use the new netmem type
abstraction, rather than use struct page directly.
As of this patch the netmem type is a no-op abstraction: it's always a
struct page underneath. All the p
API takes the dma-buf fd as input, and binds it to the netdevice. The
user can specify the rx queues to bind the dma-buf to.
Suggested-by: Stanislav Fomichev
Signed-off-by: Mina Almasry
---
v7:
- Use flags: [ admin-perm ] instead of a CAP_NET_ADMIN check.
Changes in v1:
- Add rx-queue-type to
v12: https://patchwork.kernel.org/project/netdevbpf/list/?series=859747&state=*
Major changes:
--
This iteration only addresses one minor comment from Pavel with regards
to the trace printing of netmem, and the patchwork build error
introduced in v11 because I missed doing an all
Add netdev_rx_queue_restart() function to netdev_rx_queue.h
Signed-off-by: David Wei
Signed-off-by: Mina Almasry
---
v11:
- Fix not checking dev->queue_mgmt_ops (Pavel).
- Fix ndo_queue_mem_free call that passed the wrong pointer (David).
v9: https://lore.kernel.org/all/20240502045410.3524155
On 6/12/2024 2:08 AM, Dmitry Baryshkov wrote:
On Wed, 12 Jun 2024 at 02:12, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Since SmartDMA planes provide two rectangles, it is possible to use them
to drive two different DRM planes, first plane getting the rect_0,
anoth
On Fri, 7 Jun 2024 00:51:15 + Mina Almasry wrote:
> Abstrace the memory type from the page_pool so we can later add support
> for new memory types. Convert the page_pool to use the new netmem type
> abstraction, rather than use struct page directly.
>
> As of this patch the netmem type is a n
Hi,
On Wed, Jun 12, 2024 at 03:52:55PM GMT, Tomeu Vizoso wrote:
> IOMMUs with multiple base addresses can also have multiple power
> domains.
>
> The base framework only takes care of a single power domain, as some
> devices will need for these power domains to be powered on in a specific
> order
Hello Tomeu,
On Wed, Jun 12, 2024 at 03:52:54PM GMT, Tomeu Vizoso wrote:
> So far, seems to be fully compatible with the one in the RK3568.
>
> The bindings already had this compatible, but the driver didn't
> advertise it.
>
> Signed-off-by: Tomeu Vizoso
> ---
The driver does not need to advi
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 drm_atomic
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 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 drm_atomic
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 drm_atomic
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 overview
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 system
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 drm_atomic
This patch series is the leftovers of a patch series sent in September
2023 [1] in an attempt to get some of the patches landed finally.
This patch series originally came about after a _long_ discussion
between me and Maxime Ripard in response to a different patch I sent
out [2]. As part of that
b_driver = {
module_platform_driver(goldfish_fb_driver);
+MODULE_DESCRIPTION("Goldfish Virtual Platform Framebuffer driver");
MODULE_LICENSE("GPL v2");
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-cb9dc649c945
Borislav, please review v11 implementation of 1/8 based on your proposal.
I'm waiting for your feedback before sending full v11 patchset.
Thanks,
--Alexey
On 6/6/24 4:23 PM, Alexey Makhalov wrote:
Introduce vmware_hypercall family of functions. It is a common
implementation to be used by the VMw
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head: 8f5d38cf42672216b6162952b8ad13a9b15ba78c
commit: 456e8d5810088a0b3ded31a3936062bab3984e86 [5/21] rust: introduce
`InPlaceModule`
config: x86_64-rhel-8.3-rust
(https://download.01.org/0day-ci/archive/20240613/202406130541.ar
Hi,
Le mercredi 12 juin 2024 à 23:25 +0300, Laurent Pinchart a écrit :
> On Wed, Jun 12, 2024 at 03:43:58PM -0400, Nicolas Dufresne wrote:
> > Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > > > Why is this flag needed ? Given that the usage model requires the V4L2
> > > > device
From: Ville Syrjälä
I don't think the display hardware really has such chroma
plane tile row alignment requirements as outlined in
commit d156135e6a54 ("drm/i915/tgl: Make sure a semiplanar
UV plane is tile row size aligned")
Bspec had the same exact thing to say about earlier hardware
as well,
From: Ville Syrjälä
Currently we still use the SKL+ PLANE_SURF alignment even
for TGL+ even though the hardware no longer needs it.
Introduce a separate tgl_plane_min_alignment() and update
it to more accurately reflect the hardware requirements.
v2: Don't screw up DPT+semiplanar 2MiB alignment
From: Ville Syrjälä
Now that all pre-skl platforms have their own .min_alignment()
functions the remainder of intel_surf_alignment() can be hoisted
into skl_univerals_plane.c (and renamed appropriately).
Reviewed-by: Imre Deak
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/inte
From: Ville Syrjälä
Extract the necessary chunks from intel_surf_alignment()
into per-platform variants for all pre-skl primary/sprite
planes.
Reviewed-by: Imre Deak
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 69 -
drivers/gpu/drm/i915/d
From: Ville Syrjälä
Split intel_cursor_alignment() into per-platform variants.
Reviewed-by: Imre Deak
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cursor.c | 40 +++--
drivers/gpu/drm/i915/display/intel_fb.c | 16 -
drivers/gpu/drm/i915/displ
From: Ville Syrjälä
Different planes could have different alignment requirements
even for the same format/modifier. Collect the alignment
requirements across all planes capable of scanning out the
fb such that the alignment is satisfactory to all those
planes.
So far this was sort of handle by m
From: Ville Syrjälä
Different hardware generations have different scanout alignment
requirements. Introduce a new vfunc that will allow us to
make that distinction without horrible if-ladders.
For now we directly plug in the existing intel_surf_alignment()
and intel_cursor_alignment() functions.
From: Ville Syrjälä
Rename drm_plane_check_pixel_format() to drm_plane_has_format()
and change the return type accordingly. Allows one to write
more natural code.
Also matches drm_any_plane_has_format() better.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_ato
From: Ville Syrjälä
Export drm_plane_has_format() so that drivers can use it.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc_internal.h | 2 --
drivers/gpu/drm/drm_plane.c | 1 +
include/drm/drm_plane.h | 2 ++
3 files changed, 3 inserti
From: Ville Syrjälä
intel_surf_alignment() in particular has devolved into
a complete mess. Redesign the code so that we can handle
alignment restrictions in a nicer. Also adjust alignment
for TGL+ to actually match the hardware requirements.
v2: Drop the per-plane vma stuff as it was borked
On Wed, Jun 12, 2024 at 04:37:12PM -0300, André Almeida wrote:
> Different planes may have different capabilities of doing async flips,
> so create a field to let drivers allow async flip per plane type.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
> drive
On Wed, Jun 12, 2024 at 10:51:40AM +0200, Philipp Stanner wrote:
> On Tue, 2024-06-11 at 16:44 -0500, Bjorn Helgaas wrote:
> > I'm trying to merge these into pci/next, but I'm having a hard time
> > writing the merge commit log. I want a one-sentence description of
> > each patch that tells me wha
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 03d44168cbd7fc57d5de56a3730427db758fc7f6 Add linux-next specific
files for 20240612
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202406130139.tv8i316r-...@intel.com
Error
On Wed, Jun 12, 2024 at 03:43:58PM -0400, Nicolas Dufresne wrote:
> Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > > Why is this flag needed ? Given that the usage model requires the V4L2
> > > device to be a dma buf importer, why would userspace set the
> > > V4L2_BUF_CAP_SUPPOR
On Wed, Jun 12, 2024 at 04:37:12PM -0300, André Almeida wrote:
> Different planes may have different capabilities of doing async flips,
> so create a field to let drivers allow async flip per plane type.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
> drive
On 12.06.24 15:53, Tomeu Vizoso wrote:
The NPU cores have their own access to the memory bus, and this isn't
cache coherent with the CPUs.
Add IOCTLs so userspace can mark when the caches need to be flushed, and
also when a writer job needs to be waited for before the buffer can be
accessed from
Hi,
Le mercredi 12 juin 2024 à 13:37 +0900, Tomasz Figa a écrit :
> > Why is this flag needed ? Given that the usage model requires the V4L2
> > device to be a dma buf importer, why would userspace set the
> > V4L2_BUF_CAP_SUPPORTS_RESTRICTED_MEM flag and pass a non-restricted
> > buffer to the de
amdgpu can handle async flips on overlay planes, so mark it as true
during the plane initialization.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.
Different planes may have different capabilities of doing async flips,
so create a field to let drivers allow async flip per plane type.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++--
drivers/gpu/drm/drm_plane.c | 3 +++
include/drm/drm_plane.h | 5 +
Allow userspace to use explicit synchronization with atomic async flips.
That means that the flip will wait for some hardware fence, and then
will flip as soon as possible (async) in regard of the vblank.
Signed-off-by: André Almeida
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++-
1 file changed
Hi,
AMD hardware can do async flips with overlay planes, so this patchset does a
small redesign to allow drivers to choose per plane type if they can or cannot
do async flips.
It also allows async commits with IN_FENCE_ID in any driver.
Changes from v4:
- Rebased on top current drm-misc/drm-misc
On Wed, Jun 12, 2024 at 09:43:36PM +0300, Danila Tikhonov wrote:
> Add definitions for the display hardware used on the Qualcomm SM7150
> platform.
>
> Signed-off-by: Danila Tikhonov
> ---
> .../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 349 ++
> .../gpu/drm/msm/disp/dpu1/dpu_h
On Wed, Jun 12, 2024 at 09:43:34PM +0300, Danila Tikhonov wrote:
> Add support for MDSS on SM7150.
>
> Signed-off-by: Danila Tikhonov
> ---
> drivers/gpu/drm/msm/msm_mdss.c | 8
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov
--
With best wishes
Dmitry
On Wed, Jun 12, 2024 at 10:09:42PM +0530, Tejas Vipin wrote:
> Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce
> mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
> ("drm/mipi-dsi: wrap more functions for streamline handling") for the
> sony tulip truly nt35521 panel.
On Wed, Jun 12, 2024 at 04:35:53PM +0200, Maxime Ripard wrote:
> Having lints would prove beneficial to prevent the same dark patterns
> from reoccuring over and over again in drivers.
>
> Add a TODO entry for that.
>
> Signed-off-by: Maxime Ripard
> ---
> Documentation/gpu/todo.rst | 28 ++
Document the DPU hardware found on the Qualcomm SM7150 platform.
Signed-off-by: Danila Tikhonov
---
.../bindings/display/msm/qcom,sm7150-dpu.yaml | 143 ++
1 file changed, 143 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
d
Add definitions for the display hardware used on the Qualcomm SM7150
platform.
Signed-off-by: Danila Tikhonov
---
.../msm/disp/dpu1/catalog/dpu_5_2_sm7150.h| 349 ++
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 1 +
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 1 +
Add support for MDSS on SM7150.
Signed-off-by: Danila Tikhonov
---
drivers/gpu/drm/msm/msm_mdss.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index fab6ad4e5107c..d90b9471ba6ff 100644
--- a/drivers/gpu/drm/msm/msm_md
Document the MDSS hardware found on the Qualcomm SM7150 platform.
Signed-off-by: Danila Tikhonov
---
.../display/msm/qcom,sm7150-mdss.yaml | 458 ++
1 file changed, 458 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
This series adds MDSS and DPU support for SM7150.
Changes in v2:
- Drop clock controller headers and use invented clocks instead in
patches 1 and 2 (Dmitry and Rob)
- Link to v1:
https://lore.kernel.org/all/20240611223743.113223-1-dan...@jiaxyga.com/
To: Rob Clark
To: Abhinav Kumar
To: Dmitry B
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head: 8f5d38cf42672216b6162952b8ad13a9b15ba78c
commit: 7d4e13685931d292d28484e486b5eb9ad7dba420 [3/21] rust: pass module name
to `Module::init`
config: x86_64-rhel-8.3-rust
(https://download.01.org/0day-ci/archive/20240613/202406
On Wed, Jun 12, 2024 at 12:17:28PM +0530, Ekansh Gupta wrote:
> Move fastrpc.c from misc/ to misc/fastrpc/. New C files are planned
> to be added for PD notifications and other missing features. Adding
> and maintaining new files from within fastrpc directory would be easy.
>
> Example of feature
On 06-06-24, 18:07, Marc Gonzalez wrote:
> HDMI TX block embedded in the APQ8098.
This one too
--
~Vinod
On 06-06-24, 18:07, Marc Gonzalez wrote:
> HDMI PHY block embedded in the APQ8098.
Why is the patch titled display/msm, this is phy patch and it should be
tagged as such..
Pls update
>
> Acked-by: Rob Herring (Arm)
> Signed-off-by: Marc Gonzalez
> ---
> Documentation/devicetree/bindings/phy/
Hi,
On Wed, Jun 12, 2024 at 9:47 AM Linus Walleij wrote:
>
> On Wed, Jun 12, 2024 at 5:11 PM Daniel Vetter wrote:
> > On Wed, Jun 12, 2024 at 07:49:31AM -0700, Doug Anderson wrote:
> (...)
> > > The problem is that the ordering is wrong, I think. Even if the OS was
> > > calling driver shutdown
E_AUTHOR("STMicroelectronics; Paul Mundt ");
+MODULE_DESCRIPTION("STG4000/Kyro/PowerVR 3 driver");
MODULE_LICENSE("GPL");
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-kyro-8c888247c44b
Sima,
On Wed, Jun 12, 2024 at 8:13 AM Daniel Vetter wrote:
>
> > > I ran the coccinelle script we started with, and here are the results:
> > >
> > > ./drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1640:25-39: ERROR: KMS driver
> > > vmw_pci_driver is missing shutdown implementation
> > > ./drivers/gpu/dr
On Wed, Jun 12, 2024 at 5:11 PM Daniel Vetter wrote:
> On Wed, Jun 12, 2024 at 07:49:31AM -0700, Doug Anderson wrote:
(...)
> > The problem is that the ordering is wrong, I think. Even if the OS was
> > calling driver shutdown functions in the perfect order (which I'm not
> > convinced about since
Use functions introduced in commit 966e397e4f60 ("drm/mipi-dsi: Introduce
mipi_dsi_*_write_seq_multi()") and commit f79d6d28d8fe
("drm/mipi-dsi: wrap more functions for streamline handling") for the
sony tulip truly nt35521 panel.
Reviewed-by: Douglas Anderson
Signed-off-by: Tejas Vipin
---
Chan
On Wed, Jun 12, 2024 at 03:52:56PM +0200, Tomeu Vizoso wrote:
> Add the bindings for the Neural Processing Unit IP from Rockchip.
>
> Signed-off-by: Tomeu Vizoso
> ---
> .../devicetree/bindings/npu/rockchip,rknn.yaml | 123
> +
> 1 file changed, 123 insertions(+)
>
> di
On Wed, 12 Jun 2024 at 17:32, Markus Elfring wrote:
>
> >> Would you become interested to apply a statement like
> >> “guard(mutex)(&hdmi->state_mutex);”?
> >> https://elixir.bootlin.com/linux/v6.10-rc3/source/include/linux/mutex.h#L196
> >
> > I am not.
>
> Under which circumstances will develop
On Wed, 12 Jun 2024 at 17:35, Maxime Ripard wrote:
>
> We recently added some infrastructure to deal with HDMI but we're still
> lacking a couple of things. Add a TODO entry with the remaining items.
>
> Cc: Dmitry Baryshkov
> Signed-off-by: Maxime Ripard
> ---
> Documentation/gpu/todo.rst | 29
Hi,
On Wed, Jun 12, 2024 at 8:03 AM Maxime Ripard wrote:
>
> > > Why does something like this now work?
> > >
> > > drm_panel_shutdown_fixup(panel)
> > > {
> > > /* if you get warnings here, fix your main drm driver to call
> > > * drm_atomic_helper_shutdown()
> > > */
>
Hi,
On Wed, Jun 12, 2024 at 8:11 AM Daniel Vetter wrote:
>
> > The problem is that the ordering is wrong, I think. Even if the OS was
> > calling driver shutdown functions in the perfect order (which I'm not
> > convinced about since panels aren't always child "struct device"s of
> > the DRM devi
Hi,
On Wed, Jun 12, 2024 at 8:13 AM Daniel Vetter wrote:
>
> > > I ran the coccinelle script we started with, and here are the results:
> > >
> > > ./drivers/gpu/drm/vmwgfx/vmwgfx_drv.c:1640:25-39: ERROR: KMS driver
> > > vmw_pci_driver is missing shutdown implementation
> > > ./drivers/gpu/drm/
On 11/06/2024 07:47, Vignesh Raman wrote:
Hi,
Successful pipeline link,
https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1198487
lgtm, I'm applying this tomorrow if there are no more comments.
Regards,
Helen
Regards,
Vignesh
On 11/06/24 14:40, Vignesh Raman wrote:
Add job
Hello:
This patch was applied to jaegeuk/f2fs.git (dev)
by Steven Rostedt (Google) :
On Thu, 16 May 2024 13:34:54 -0400 you wrote:
> From: "Steven Rostedt (Google)"
>
> [
>This is a treewide change. I will likely re-create this patch again in
>the second week of the merge window of v6.1
CENSE("GPL");
#endif
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-via-3d7df315eee7
On 6/12/24 6:06 AM, Jason Gunthorpe wrote:
> On Tue, Jun 11, 2024 at 11:09:15AM -0700, Mina Almasry wrote:
>
>> Just curious: in Pavel's effort, io_uring - which is not a device - is
>> trying to share memory with the page_pool, which is also not a device.
>> And Pavel is being asked to wrap the m
mipi_dsi_msleep is currently defined such that it treats ctx as an
argument passed by value. In the case of ctx being passed by
reference, it doesn't raise an error, but instead evaluates the
resulting expression in an undesired manner. Since the majority of the
usage of this function passes ctx by
mipi_dsi_msleep should be modified to accept ctx as a pointer and the
function call should be adjusted accordingly.
Fixes: a2ab7cb169da3 ("drm/panel: himax-hx83102: use wrapped MIPI DCS
functions")
Signed-off-by: Tejas Vipin
---
drivers/gpu/drm/panel/panel-himax-hx83102.c | 6 +++---
1 file ch
ctx would be better off treated as a pointer to account for most of its
usage so far, and brackets should be added to account for operator
precedence for correct evaluation.
Fixes: f79d6d28d8fe7 ("drm/mipi-dsi: wrap more functions for streamline
handling")
Signed-off-by: Tejas Vipin
---
inclu
s for Matrox
Millennium/Mystique/G100/G200/G400/G450/G550");
MODULE_LICENSE("GPL");
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240612-md-drivers-video-fbdev-matrox-44ec428aa97a
1 - 100 of 205 matches
Mail list logo
