On Sun, 18 May 2025 22:54:10 +, Jonas Karlman wrote:
> This series adds support for the Mali-450 MP2 GPU in the RK3528 SoC.
>
> The clock used for the GPU can use normal PLL to support a rate of 100,
> 300 or 500 MHz. Or it can use PVTPLL to reach rates up to 800 MHz.
>
> The TF-A SCMI_CLK_
This series adds support for the Mali-450 MP2 GPU in the RK3528 SoC.
The clock used for the GPU can use normal PLL to support a rate of 100,
300 or 500 MHz. Or it can use PVTPLL to reach rates up to 800 MHz.
The TF-A SCMI_CLK_GPU is used to switch use between normal PLL and
PVTPLL. When a rate of
On Thu May 15, 2025 at 3:26 PM JST, Alexandre Courbot wrote:
> I noticed this after trying to understand why my minimal Nova defconfig
> was not selecting NOVA_CORE anymore and why I couldn't even find it in
> menuconfig.
>
> CONFIG_AUXILIARY_BUS cannot be enabled directly and must be selected by
>
I noticed this after trying to understand why my minimal Nova defconfig
was not selecting NOVA_CORE anymore and why I couldn't even find it in
menuconfig.
CONFIG_AUXILIARY_BUS cannot be enabled directly and must be selected by
another module. Options that depend on it thus cannot be enabled unless
Hi,
just a small series to cleanup the fsl-ldb lvds bridge driver a bit.
Regards,
Marco
Marco Felsch (3):
drm/bridge: fsl-ldb: make use of driver_private
drm/bridge: fsl-ldb: make use of dev_err_probe
drm/bridge: fsl-ldb: simplify device_node error handling
drivers/gpu/drm/bridge/fsl-ldb
From: "Dr. David Alan Gilbert"
Hi,
A few more AMD deadcoding patches spinning out of the
questions I asked, and Kenneth answered.
See:
https://lore.kernel.org/all/dm4pr12mb5165d85bd85bc8fc8bf7a3b48e...@dm4pr12mb5165.namprd12.prod.outlook.com/
Dave
Signed-off-by: Dr. David Alan Gilbert
From: "Dr. David Alan Gilbert"
Hi,
A bunch more deadcode around the AMD GPUs.
(I've not done smu_v14 which all looks rather new
to me, so perhaps you're still intending to use
some of the unused functions).
Signed-off-by: Dr. David Alan Gilbert
Dr. David Alan Gilbert (3):
drm/amd/pm/smu7:
Dear All,
This patchset fixes the incorrect use of dma_sync_sg_*() calls in
media and related drivers. They are replaced with much safer
dma_sync_sgtable_*() variants, which take care of passing the proper
number of elements for the sync operation.
Best regards
Marek Szyprowski, PhD
Samsung R&D I
When a VIRTIO GPU device is removed, it cleans up any command buffers
that the VIRTIO frontend has responded to. It however ignores commands
that have yet to be replied to, which still reside in the avail rings of
the virt queues. This leaks two type of objects:
- VIRTIO command buffers
- Fences
This patch series is a Panfrost port of the already merged patches
previously discussed at [1].
The differences are minimal. However, Panfrost doesn't have Kernel-only BO's,
so all the
functionality that dealt with them has been removed.
The under-discussion Mesa MR that would allow one to test
On Mon, Apr 14, 2025 at 09:21:25PM +0200, Thomas Petazzoni wrote:
> > "UIO is a broken legacy mess, so let's add more broken things
> > to it as broken + broken => still broken, so no harm done", am I
> > getting that right?
>
> Who says UIO is a "broken legacy mess"? Only you says so. I don't se
This patch set documents Adreno 505/506/510 clocks
with the missing alwayson clock and enforce their order.
Signed-off-by: Barnabás Czémán
---
Barnabás Czémán (3):
dt-bindings: display/msm/gpu: Document clocks of Adreno 505/506/510
arm64: dts: qcom: msm8953: sort adreno clocks
a
This patchset modifies the migration part of drm_gpusvm to drm_pagemap and
adds a populate_mm() op to drm_pagemap.
The idea is that the device that receives a pagefault determines if it wants to
migrate content and to where. It then calls the populate_mm() method of relevant
drm_pagemap.
This fun
On 4/14/25 2:21 PM, Thomas Petazzoni wrote:
Hello Andrew,
On Mon, 14 Apr 2025 12:08:44 -0500
Andrew Davis wrote:
"UIO is a broken legacy mess, so let's add more broken things
to it as broken + broken => still broken, so no harm done", am I
getting that right?
Who says UIO is a "broken legac
On 4/14/25 6:48 AM, Thomas Petazzoni wrote:
Hello Christoph,
On Mon, 14 Apr 2025 04:24:21 -0700
Christoph Hellwig wrote:
On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote:
What this patch series is about is to add new user-space interface to
extend the existing UIO subsystem.
Hello Andrew,
On Mon, 14 Apr 2025 12:08:44 -0500
Andrew Davis wrote:
> "UIO is a broken legacy mess, so let's add more broken things
> to it as broken + broken => still broken, so no harm done", am I
> getting that right?
Who says UIO is a "broken legacy mess"? Only you says so. I don't see
any
Hello Christian,
On Mon, 14 Apr 2025 11:11:48 +0200
Christian König wrote:
> Maybe I should try to better explain the concern here. The question
> is "Where is the source code of your FPGA driver?".
>
> I mean that you are trying to replace the out-of-tree solution is
> rather welcomed, but the
Hello Christoph,
On Mon, 14 Apr 2025 04:24:21 -0700
Christoph Hellwig wrote:
> On Mon, Apr 14, 2025 at 10:24:55AM +0200, Thomas Petazzoni wrote:
> > What this patch series is about is to add new user-space interface to
> > extend the existing UIO subsystem.
>
> Which as I explained to you is
Am 14.04.25 um 10:24 schrieb Thomas Petazzoni:
> Hello Christoph,
>
> On Sun, 13 Apr 2025 22:55:02 -0700
> Christoph Hellwig wrote:
>
>> On Thu, Apr 10, 2025 at 04:53:17PM +0200, Bastien Curutchet wrote:
>>> Hi all,
>>>
>>> Many UIO users performing DMA from their UIO device need to access the
>>>
Hello Christian,
On Fri, 11 Apr 2025 14:41:56 +0200
Christian König wrote:
> But anyway please note that when you want to create new UAPI you need
> to provide an open source user of it. E.g. link to a repository or
> something similar in the covert letter should do it.
Could you clarify what i
Am 14.04.25 um 10:17 schrieb Thomas Petazzoni:
> Hello Christian,
>
> On Fri, 11 Apr 2025 14:41:56 +0200
> Christian König wrote:
>
>> But anyway please note that when you want to create new UAPI you need
>> to provide an open source user of it. E.g. link to a repository or
>> something similar in
Hello Christoph,
On Sun, 13 Apr 2025 22:55:02 -0700
Christoph Hellwig wrote:
> On Thu, Apr 10, 2025 at 04:53:17PM +0200, Bastien Curutchet wrote:
> > Hi all,
> >
> > Many UIO users performing DMA from their UIO device need to access the
> > DMA addresses of the allocated buffers. There are out-
Hi Bastien,
Am 11.04.25 um 10:14 schrieb Bastien Curutchet:
> Hi Christian,
>
> On 4/11/25 9:30 AM, Christian König wrote:
>> Hi Thomas,
>>
>> Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
>>> Hello Christian,
>>>
>>> Thanks for your feedback!
>>>
>>> On Thu, 10 Apr 2025 18:29:12 +0200
>>> Christ
Hi Christian,
On 4/11/25 9:30 AM, Christian König wrote:
Hi Thomas,
Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
Hello Christian,
Thanks for your feedback!
On Thu, 10 Apr 2025 18:29:12 +0200
Christian König wrote:
Many UIO users performing DMA from their UIO device need to access the
DMA
Hi Thomas,
Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
> Hello Christian,
>
> Thanks for your feedback!
>
> On Thu, 10 Apr 2025 18:29:12 +0200
> Christian König wrote:
>
>>> Many UIO users performing DMA from their UIO device need to access the
>>> DMA addresses of the allocated buffers. There
Hello,
This small patch series builds on top of the R-Car VSP1 color space
support ("[PATCH 0/6] media: renesas: vsp1: Add colorspace support",
posted as [1]) to implement the KMS plane color space properties in the
R-Car DU driver.
The first two patches add support to specify plane color encodin
Hello Christian,
Thanks for your feedback!
On Thu, 10 Apr 2025 18:29:12 +0200
Christian König wrote:
> > Many UIO users performing DMA from their UIO device need to access the
> > DMA addresses of the allocated buffers. There are out-of-tree drivers
> > that allow to do it but nothing in the ma
On Thu, 2025-04-10 at 11:24 +0200, Philipp Stanner wrote:
> Contains two patches improving nouveau_fence_done(), and one
> addressing
> an actual bug (race):
Oops, that's the wrong calltrace. Here we go:
[ 85.791794] Call Trace: [ 85.791796] [ 85.791797] ?
nouveau_fence_context_kill
(/home/imp
Am 10.04.25 um 16:53 schrieb Bastien Curutchet:
> Hi all,
>
> Many UIO users performing DMA from their UIO device need to access the
> DMA addresses of the allocated buffers. There are out-of-tree drivers
> that allow to do it but nothing in the mainline.
Well that basically disqualifies this patc
Hi all,
Many UIO users performing DMA from their UIO device need to access the
DMA addresses of the allocated buffers. There are out-of-tree drivers
that allow to do it but nothing in the mainline.
I know DMA shouldn't be handled by userspace but, IMHO, since UIO
drivers exist, it would be better
On Thu, 2025-04-10 at 14:18 +0200, Christian König wrote:
> Am 10.04.25 um 11:51 schrieb Philipp Stanner:
> > On Thu, 2025-04-10 at 11:24 +0200, Philipp Stanner wrote:
> > > Contains two patches improving nouveau_fence_done(), and one
> > > addressing
> > > an actual bug (race):
> > Oops, that's th
Am 10.04.25 um 11:51 schrieb Philipp Stanner:
> On Thu, 2025-04-10 at 11:24 +0200, Philipp Stanner wrote:
>> Contains two patches improving nouveau_fence_done(), and one
>> addressing
>> an actual bug (race):
> Oops, that's the wrong calltrace. Here we go:
>
> [ 85.791794] Call Trace: [ 85.791796]
Contains two patches improving nouveau_fence_done(), and one addressing
an actual bug (race):
[ 39.848463] WARNING: CPU: 21 PID: 1734 at
drivers/gpu/drm/nouveau/nouveau_fence.c:509
nouveau_fence_no_signaling+0xac/0xd0 [nouveau]
[ 39.848551] Modules linked in: snd_seq_dummy snd_hrtimer
nf_co
Drivers for system framebuffers validate the provided values against
limits. Share most of the driver code in the sysfb helper library and
update drivers.
Thomas Zimmermann (3):
drm/sysfb: Split source file
drm/sysfb: Share helpers for integer validation
drm/sysfb: Share helpers for screen_i
From: Michael Kelley
Current deferred I/O code works only for framebuffer memory that is
allocated with vmalloc(). The code assumes that the underlying page
refcount can be used by the mm subsystem to manage each framebuffer
page's lifecycle, which is consistent with vmalloc'ed memory, but not
wi
Hi,
thanks for following up on this.
You could've added some detail about what the patchset is doing.
--Imre
On Tue, Apr 08, 2025 at 09:40:33AM +0530, Arun R Murthy wrote:
> Signed-off-by: Arun R Murthy
> ---
> Arun R Murthy (3):
> drm/drm_dp_helper: export link symbol cycles calculation
Signed-off-by: Arun R Murthy
---
Arun R Murthy (3):
drm/drm_dp_helper: export link symbol cycles calculation
drm/i915/display: export function to count dsc slices
drm/i915/audio: move min_hblank from dp_mst to audio
drivers/gpu/drm/display/drm_dp_helper.c | 10 ++--
drivers
This series add support for the ST7571 LCD Controller.
It is a 4 gray scale dot matrix LCD controller that supports several
interfaces such as SPI, I2C and a 8bit parallell port.
This driver only supports the I2C interface, but all common parts could
easily be put into a common file to be used wit
+ Anshuman Khandual, Catalin Marinas, linux-arm-ker...@lists.infradead.org
This series moves GENMASK_U128 out of uapi. ARM is the only proposed
user. Add ARM people for visibility.
Thanks,
Yury
On Sat, Mar 22, 2025 at 07:39:35PM +0900, Vincent Mailhol via B4 Relay wrote:
> This is a subset of be
Hello,
This is a collection of fixes for bugs found while working on adding
JM support to panthor. Those are not particularly tied to JM support
and are worth having regardless.
Note that the last one doesn't have a Fixes tag because all MMU faults
are considered fatal right now, so unblocking th
On Fri, Mar 21, 2025 at 02:49:20PM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 21, 2025 at 01:12:30PM +0100, Danilo Krummrich wrote:
>
> > Not all device resources are managed in the context of the subsystem, so
> > subsystem-level revokes do not apply.
>
> They could, you could say that these ru
On 25/03/2025 at 01:11, Yury Norov wrote:
> + Anshuman Khandual, Catalin Marinas, linux-arm-ker...@lists.infradead.org
>
> This series moves GENMASK_U128 out of uapi. ARM is the only proposed
> user. Add ARM people for visibility.
Actually, not yet. Here, I am decoupling GENMASK_U128() from
__GEN
Three small fixes for ast to resolve a few minor issues. Tested on
AST2600 hardware.
Thomas Zimmermann (3):
drm/ast: Fix comment on modeset lock
drm/ast: Remove vaddr field from struct ast_plane
drm/ast: Validate display modes against framebuffer and format limits
drivers/gpu/drm/ast/ast_c
This is a subset of below series:
bits: Fixed-type GENMASK_U*() and BIT_U*()
Link:
https://lore.kernel.org/r/20250308-fixed-type-genmasks-v6-0-f59315e73...@wanadoo.fr
Yury suggested to split the above series in two steps:
#1 Introduce the new fixed type GENMASK_U*()
#2 Consolidate the e
On Fri, Mar 21, 2025 at 01:12:30PM +0100, Danilo Krummrich wrote:
> Not all device resources are managed in the context of the subsystem, so
> subsystem-level revokes do not apply.
They could, you could say that these rust APIs are only safe to use
for device drivers with C code providing a fence
On Fri, Mar 21, 2025 at 11:35:40AM +0100, Simona Vetter wrote:
> On Wed, Mar 19, 2025 at 02:21:32PM -0300, Jason Gunthorpe wrote:
> > On Thu, Mar 13, 2025 at 03:32:14PM +0100, Simona Vetter wrote:
> >
> > > So I think you can still achieve that building on top of revocable and a
> > > few more abs
On Fri, Mar 21, 2025 at 09:04:16AM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 21, 2025 at 11:35:40AM +0100, Simona Vetter wrote:
> > On Wed, Mar 19, 2025 at 02:21:32PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Mar 13, 2025 at 03:32:14PM +0100, Simona Vetter wrote:
> > >
> > > > So I think you c
On Wed, Mar 19, 2025 at 02:21:32PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 13, 2025 at 03:32:14PM +0100, Simona Vetter wrote:
>
> > So I think you can still achieve that building on top of revocable and a
> > few more abstractions that are internally unsafe. Or are you thinking of
> > differen
On Thu, Mar 13, 2025 at 03:32:14PM +0100, Simona Vetter wrote:
> So I think you can still achieve that building on top of revocable and a
> few more abstractions that are internally unsafe. Or are you thinking of
> different runtime checks?
I'm thinking on the access side of the revocable you don
This patch series implements the Vec::truncate and Vec::resize methods
that were needed by the nova driver and removes the corresponding item
from their task list
Andrew Ballance (3):
rust: alloc: add Vec::truncate method
rust: alloc: add Vec::resize method
gpu: nova-core: remove completed V
Hi Andrew,
On Fri, Mar 14, 2025 at 09:42:32PM -0500, Andrew Ballance wrote:
> This patch series implements the Vec::truncate and Vec::resize methods
> that were needed by the nova driver and removes the corresponding item
> from their task list
>
> Andrew Ballance (3):
> rust: alloc: add Vec::t
On Fri, Mar 07, 2025 at 10:55:57AM -0400, Jason Gunthorpe wrote:
> On Fri, Mar 07, 2025 at 02:09:12PM +0100, Simona Vetter wrote:
>
> > > A driver can do a health check immediately in remove() and make a
> > > decision if the device is alive or not to speed up removal in the
> > > hostile hot unpl
On Fri, Mar 07, 2025 at 02:09:12PM +0100, Simona Vetter wrote:
> > A driver can do a health check immediately in remove() and make a
> > decision if the device is alive or not to speed up removal in the
> > hostile hot unplug case.
>
> Hm ... I guess when you get an all -1 read you check with a s
On Fri, Mar 07, 2025 at 04:19:30PM +0100, Greg KH wrote:
> Just like other busses, if PCI can't handle this at the core hotplug
> layer (i.e. by giving up new resources to new devices) then the bus core
> for it should handle this type of locking scheme as really, that feels
> wrong. A new device
On Fri, Mar 07, 2025 at 10:46:29AM -0400, Jason Gunthorpe wrote:
> On Fri, Mar 07, 2025 at 03:00:09PM +0100, Greg KH wrote:
> > On Fri, Mar 07, 2025 at 08:32:55AM -0400, Jason Gunthorpe wrote:
> > > On Fri, Mar 07, 2025 at 11:28:37AM +0100, Simona Vetter wrote:
> > >
> > > > > I wouldn't say it is
This short series adds power on/off timings to the Tianma TM070JDHG34-00
panel and adds support for the the Tianma P0700WXF1MBAA panel.
Signed-off-by: Luca Ceresoli
---
Luca Ceresoli (3):
dt-bindings: display: simple: Add Tianma P0700WXF1MBAA panel
drm/panel: simple: Tianma TM070JDHG3
On Fri, Mar 07, 2025 at 03:00:09PM +0100, Greg KH wrote:
> On Fri, Mar 07, 2025 at 08:32:55AM -0400, Jason Gunthorpe wrote:
> > On Fri, Mar 07, 2025 at 11:28:37AM +0100, Simona Vetter wrote:
> >
> > > > I wouldn't say it is wrong. It is still the correct thing to do, and
> > > > following down the
On Fri, Mar 07, 2025 at 08:32:55AM -0400, Jason Gunthorpe wrote:
> On Fri, Mar 07, 2025 at 11:28:37AM +0100, Simona Vetter wrote:
>
> > > I wouldn't say it is wrong. It is still the correct thing to do, and
> > > following down the normal cleanup paths is a good way to ensure the
> > > special cas
On Fri, Mar 07, 2025 at 08:32:55AM -0400, Jason Gunthorpe wrote:
> On Fri, Mar 07, 2025 at 11:28:37AM +0100, Simona Vetter wrote:
>
> > > I wouldn't say it is wrong. It is still the correct thing to do, and
> > > following down the normal cleanup paths is a good way to ensure the
> > > special cas
On Fri, Mar 07, 2025 at 11:28:37AM +0100, Simona Vetter wrote:
> > I wouldn't say it is wrong. It is still the correct thing to do, and
> > following down the normal cleanup paths is a good way to ensure the
> > special case doesn't have bugs. The primary difference is you want to
> > understand t
On Thu, Mar 06, 2025 at 11:32:36AM -0400, Jason Gunthorpe wrote:
> On Thu, Mar 06, 2025 at 11:42:38AM +0100, Simona Vetter wrote:
> > > Further, I just remembered, (Danilo please notice!) there is another
> > > related issue here that DMA mappings *may not* outlive remove()
> > > either. netdev had
On Thu, Mar 06, 2025 at 11:42:38AM +0100, Simona Vetter wrote:
> > Further, I just remembered, (Danilo please notice!) there is another
> > related issue here that DMA mappings *may not* outlive remove()
> > either. netdev had a bug related to this recently and it was all
> > agreed that it is not
On Wed, Mar 05, 2025 at 11:10:12AM -0400, Jason Gunthorpe wrote:
> On Wed, Mar 05, 2025 at 08:30:34AM +0100, Simona Vetter wrote:
> > - developers who want to quickly test new driver versions without full
> > reboot. They're often preferring convenience over correctness, like with
> > the remov
On Wed, Mar 05, 2025 at 08:30:34AM +0100, Simona Vetter wrote:
> - developers who want to quickly test new driver versions without full
> reboot. They're often preferring convenience over correctness, like with
> the removal of module refcounting that's strictly needed but means they
> first
On Tue, Mar 04, 2025 at 12:42:01PM -0400, Jason Gunthorpe wrote:
> On Tue, Mar 04, 2025 at 05:10:45PM +0100, Simona Vetter wrote:
> > On Fri, Feb 28, 2025 at 02:40:13PM -0400, Jason Gunthorpe wrote:
> > > On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
> > >
> > > > - Nuke the drive
On Tue, Mar 04, 2025 at 05:10:45PM +0100, Simona Vetter wrote:
> On Fri, Feb 28, 2025 at 02:40:13PM -0400, Jason Gunthorpe wrote:
> > On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
> >
> > > - Nuke the driver binding manually through sysfs with the unbind files.
> > > - Nuke all us
On Fri, Feb 28, 2025 at 02:40:13PM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
>
> > - Nuke the driver binding manually through sysfs with the unbind files.
> > - Nuke all userspace that might beholding files and other resources open.
> > - At thi
On Mon, Mar 03, 2025 at 05:50:02PM -0400, Jason Gunthorpe wrote:
> On Mon, Mar 03, 2025 at 08:36:34PM +0100, Danilo Krummrich wrote:
> > > > And yes, for *device resources* it is unsound if we do not ensure that
> > > > the
> > > > device resource is actually dropped at device unbind.
> > >
> > >
On Mon, Mar 03, 2025 at 08:36:34PM +0100, Danilo Krummrich wrote:
> > > And yes, for *device resources* it is unsound if we do not ensure that the
> > > device resource is actually dropped at device unbind.
> >
> > Why not do a runtime validation then?
> >
> > It would be easy to have an atomic c
On Fri, Feb 28, 2025 at 02:55:34PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 11:40:53PM +0100, Danilo Krummrich wrote:
> > On Thu, Feb 27, 2025 at 06:00:13PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Feb 27, 2025 at 01:25:10PM -0800, Boqun Feng wrote:
> > > >
> > > > Most of the ca
The udl drivers prints warnings about dropped URBs from its disconnect
handler. This is because the poll helper doesn't yet know that the USB
device is gone. Fix the disconnect clean-up logic and use managed cleanup
for poll helpers.
Thomas Zimmermann (3):
drm/udl: Unregister device before clean
On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
> - Nuke the driver binding manually through sysfs with the unbind files.
> - Nuke all userspace that might beholding files and other resources open.
> - At this point the module refcount should be zero and you can unload it.
>
> Exce
On Thu, Feb 27, 2025 at 11:40:53PM +0100, Danilo Krummrich wrote:
> On Thu, Feb 27, 2025 at 06:00:13PM -0400, Jason Gunthorpe wrote:
> > On Thu, Feb 27, 2025 at 01:25:10PM -0800, Boqun Feng wrote:
> > >
> > > Most of the cases, it should be naturally achieved, because you already
> > > bind the ob
On Fri, Feb 28, 2025 at 02:10:39PM +1000, Dave Airlie wrote:
> On Fri, 28 Feb 2025 at 09:07, John Hubbard wrote:
> >
> > On Thu Feb 27, 2025 at 1:42 PM PST, Dave Airlie wrote:
> > > On Thu, 27 Feb 2025 at 11:34, John Hubbard wrote:
> > >> On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
> > >>
On Wed, Feb 26, 2025 at 05:34:01PM -0800, John Hubbard wrote:
> On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
> > On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> >> The way misc device works you can't unload the module until all the
> >> FDs are closed and the misc code dire
On Thu, 27 Feb 2025 at 11:34, John Hubbard wrote:
>
> On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
> > On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> >> The way misc device works you can't unload the module until all the
> >> FDs are closed and the misc code directly hand
On Fri, 28 Feb 2025 at 09:07, John Hubbard wrote:
>
> On Thu Feb 27, 2025 at 1:42 PM PST, Dave Airlie wrote:
> > On Thu, 27 Feb 2025 at 11:34, John Hubbard wrote:
> >> On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
> >> > On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> ...
On Fri, 28 Feb 2025 at 11:49, Timur Tabi wrote:
>
> On Fri, 2025-02-28 at 07:37 +1000, Dave Airlie wrote:
> > I've tried to retrofit checking 0x to drivers a lot, I'd
> > prefer not to. Drivers getting stuck in wait for clear bits for ever.
>
> That's what read_poll_timeout() is for. I'm
On Fri, 2025-02-28 at 07:37 +1000, Dave Airlie wrote:
> I've tried to retrofit checking 0x to drivers a lot, I'd
> prefer not to. Drivers getting stuck in wait for clear bits for ever.
That's what read_poll_timeout() is for. I'm surprised Nouveau doesn't use it.
On Thu Feb 27, 2025 at 1:42 PM PST, Dave Airlie wrote:
> On Thu, 27 Feb 2025 at 11:34, John Hubbard wrote:
>> On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
>> > On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
...
> nova is just a drm driver, it's not a rewrite of the drm subs
On Thu, Feb 27, 2025 at 03:23:21PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 06:32:15PM +0100, Danilo Krummrich wrote:
> > On Thu, Feb 27, 2025 at 08:55:09AM -0800, Boqun Feng wrote:
> > > On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote:
> > >
> > > > I still wonder w
On Thu, Feb 27, 2025 at 06:00:13PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 01:25:10PM -0800, Boqun Feng wrote:
> >
> > Most of the cases, it should be naturally achieved, because you already
> > bind the objects into your module or driver, otherwise they would be
> > already cancel
On Thu, Feb 27, 2025 at 01:25:10PM -0800, Boqun Feng wrote:
> > The design pattern says that 'share it with the rest of the world' is
> > a bug. A driver following the pattern cannot do that, it must contain
> > the driver objects within the driver scope and free them. In C we
>
> I cannot speak f
On Wed, 26 Feb 2025 at 00:11, Alexandre Courbot wrote:
>
> On Mon Feb 24, 2025 at 9:07 PM JST, Danilo Krummrich wrote:
> > CC: Gary
> >
> > On Mon, Feb 24, 2025 at 10:40:00AM +0900, Alexandre Courbot wrote:
> >> This inability to sleep while we are accessing registers seems very
> >> constraining
On Thu, Feb 27, 2025 at 06:32:15PM +0100, Danilo Krummrich wrote:
> On Thu, Feb 27, 2025 at 08:55:09AM -0800, Boqun Feng wrote:
> > On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote:
> >
> > > I still wonder why you couldn't also have these reliable reference
> > > counts rooted on t
On Thu, Feb 27, 2025 at 08:55:09AM -0800, Boqun Feng wrote:
> On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote:
>
> > I still wonder why you couldn't also have these reliable reference
> > counts rooted on the device driver instead of only on the module.
> >
>
> You could put reli
On Thu, Feb 27, 2025 at 12:17:33PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 07:18:02AM -0800, Boqun Feng wrote:
> > On Thu, Feb 27, 2025 at 10:46:18AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Feb 26, 2025 at 04:41:08PM -0800, Boqun Feng wrote:
> > > > And if you don't store the Hr
On Thu, Feb 27, 2025 at 11:07:09AM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 27, 2025 at 12:32:45PM +0100, Danilo Krummrich wrote:
> > On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> > > On Wed, Feb 26, 2025 at 10:31:10PM +0100, Danilo Krummrich wrote:
> > > > Let's take a step
On Thu, Feb 27, 2025 at 07:18:02AM -0800, Boqun Feng wrote:
> On Thu, Feb 27, 2025 at 10:46:18AM -0400, Jason Gunthorpe wrote:
> > On Wed, Feb 26, 2025 at 04:41:08PM -0800, Boqun Feng wrote:
> > > And if you don't store the HrTimerHandle anywhere, like you drop() it
> > > right after start a hrtime
On Thu, Feb 27, 2025 at 10:46:18AM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 26, 2025 at 04:41:08PM -0800, Boqun Feng wrote:
> > And if you don't store the HrTimerHandle anywhere, like you drop() it
> > right after start a hrtimer, it will immediately stop the timer. Does
> > this make sense?
>
On Thu, Feb 27, 2025 at 12:32:45PM +0100, Danilo Krummrich wrote:
> On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> > On Wed, Feb 26, 2025 at 10:31:10PM +0100, Danilo Krummrich wrote:
> > > Let's take a step back and look again why we have Devres (and Revocable)
> > > for
> > >
On Wed, Feb 26, 2025 at 04:41:08PM -0800, Boqun Feng wrote:
> And if you don't store the HrTimerHandle anywhere, like you drop() it
> right after start a hrtimer, it will immediately stop the timer. Does
> this make sense?
Oh, I understand that, but it is not sufficient in the kernel.
You are mak
On Wed, Feb 26, 2025 at 05:02:23PM -0800, Greg KH wrote:
> On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> > The way misc device works you can't unload the module until all the
> > FDs are closed and the misc code directly handles races with opening
> > new FDs while modules are
On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 26, 2025 at 10:31:10PM +0100, Danilo Krummrich wrote:
> > Let's take a step back and look again why we have Devres (and Revocable) for
> > e.g. pci::Bar.
> >
> > The device / driver model requires that device resources
On Wed Feb 26, 2025 at 5:02 PM PST, Greg KH wrote:
> On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
>> The way misc device works you can't unload the module until all the
>> FDs are closed and the misc code directly handles races with opening
>> new FDs while modules are unloading
On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
> The way misc device works you can't unload the module until all the
> FDs are closed and the misc code directly handles races with opening
> new FDs while modules are unloading. It is quite a different scheme
> than discussed in thi
On Wed, Feb 26, 2025 at 07:47:30PM -0400, Jason Gunthorpe wrote:
[...]
>
> > Other abstractions do consider this though, e.g. the upcoming hrtimer work.
> > [1]
>
> Does it??? hrtimer uses function pointers. Any time you take a
> function pointer you have to reason about how does the .text lifet
On Wed, Feb 26, 2025 at 10:31:10PM +0100, Danilo Krummrich wrote:
> Let's take a step back and look again why we have Devres (and Revocable) for
> e.g. pci::Bar.
>
> The device / driver model requires that device resources are only held by a
> driver, as long as the driver is bound to the device.
On Wed, Feb 26, 2025 at 01:21:20PM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 26, 2025 at 02:16:58AM +0100, Danilo Krummrich wrote:
> > Again, the reason a pci::Bar needs to be revocable in Rust is that we can't
> > have
> > the driver potentially keep the pci::Bar alive (or even access it) after
On Wed, Feb 26, 2025 at 02:16:58AM +0100, Danilo Krummrich wrote:
> > DRM achieves this, in part, by using drm_dev_unplug().
>
> No, DRM can have concurrent driver code running, which is why drm_dev_enter()
> returns whether the device is unplugged already, such that subsequent
> operations, (e.g.
1 - 100 of 1401 matches
Mail list logo
