Prepare for the introduction of a fixed-name CMA heap by replacing the
unused void pointer parameter in __add_cma_heap() with the heap name.
Reviewed-by: Maxime Ripard
Signed-off-by: Jared Kangas
---
drivers/dma-buf/heaps/cma_heap.c | 18 +++---
1 file changed, 11 insertions(+), 7 d
> -Original Message-
> From: Intel-gfx On Behalf Of Imre
> Deak
> Sent: Monday, 9 June 2025 15.56
> To: intel-...@lists.freedesktop.org; intel...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org
> Cc: Ville Syrjälä ; Jani Nikula
>
> Subject: [PATCH v
The CMA heap's name in devtmpfs can vary depending on how the heap is
defined. Its name defaults to "reserved", but if a CMA area is defined
in the devicetree, the heap takes on the devicetree node's name, such as
"default-pool" or "linux,cma". To simplify naming, unconditionally name
it "default_c
Code snippets should be wrapped in double backticks to follow
reStructuredText semantics; the use of single backticks uses the
:title-reference: role by default, which isn't quite what we want.
Add double backticks to code snippets to fix this.
Reviewed-by: Maxime Ripard
Signed-off-by: Jared Kang
Hi all,
This patch series is based on a previous discussion around CMA heap
naming. [1] The heap's name depends on the device name, which is
generally "reserved", "linux,cma", or "default-pool", but could be any
arbitrary name given to the default CMA area in the devicetree. For a
consistent users
; linux-me...@vger.kernel.org; dri-
>> de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; linux-
>> ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
>> m...@kvack.org; wangbintian(BintianWang) ;
>> yipengxiang ; liulu 00013167
>> ; hanfeng 00012985
Helper which fails to consolidate the code and instead just forks into two
copies of the code based on a boolean parameter is not very helpful or
readable. Lets just remove it and proof in the pudding is the net smaller
code.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra Canal
---
v2:
* Assi
We can avoid one of the two temporary allocations if we read the userspace
supplied timeline points as we go along.
The only new complication is to unwind unused fence chains on the error
path, but even that code was already present in the function.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maí
Drm_syncobj_array_find() helper is used from many userspace ioctl entry
points with the task of looking up userspace handles to internal objects.
We can easily avoid one temporary allocation by making it read the handles
as it is looking them up.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra
Running the Cyberpunk 2077 benchmark we can observe that waiting on DRM
sycobjs is relatively hot, but the 96% of the calls are for a single
object. (~4% for two points, and never more than three points. While
a more trivial workload like vkmark under Plasma is even more skewed
to single point wait
Running the Cyberpunk 2077 benchmark we can observe that the lookup helper
is relatively hot, but the 97% of the calls are for a single object. (~3%
for two points, and never more than three points. While a more trivial
workload like vkmark under Plasma is even more skewed to single point
lookups.)
A small set of drm_syncobj optimisations which should make things a tiny bit
more efficient on the CPU side of things.
Improvement seems to be around 1.5%* more FPS if observed with "vkgears
-present-mailbox" on a Steam Deck Plasma desktop, but I am reluctant to make a
definitive claim on the numb
When waiting on syncobjs the current code allocates a temporary array only
to fill it up with all zeros.
We can avoid that by relying on the allocated entry array already being
zero allocated.
For the timeline mode we can fetch the timeline point values as we
populate the entries array so also do
Hi,
Should I go ahead make the diagram more detailed or just add the links
in 'Slides and articles' & 'Conference talks' to the existing
diagram?
Best regards,
On Wed, Jun 4, 2025 at 10:37 AM Simona Vetter wrote:
>
> On Mon, Jun 02, 2025 at 08:28:30AM +0700, Bagas Sanjaya wrote:
> > On Sun, Ju
On Mon, May 12, 2025 at 04:06:45PM +0100, Matthew Auld wrote:
> Goal here is cut over to gpusvm and remove xe_hmm, relying instead on
> common code. The core facilities we need are get_pages(), unmap_pages()
> and free_pages() for a given useptr range, plus a vm level notifier
> lock, which is now
On Mon, May 12, 2025 at 04:06:44PM +0100, Matthew Auld wrote:
> This will simplify compiling out the bits that depend on DRM_GPUSVM in a
> later patch. Without this we end up littering the code with ifdef
> checks, plus it becomes hard to be sure that something won't blow at
> runtime due to someth
Hi,
On Mon, Jun 9, 2025 at 6:02 AM Jerome Brunet wrote:
>
> On Tue 25 Feb 2025 at 08:04, Doug Anderson wrote:
>
> > Hi,
> >
> > On Tue, Feb 18, 2025 at 11:30 AM Jerome Brunet wrote:
> >>
> >> The auxiliary device creation of this driver is simple enough to
> >> use the available auxiliary devic
Reading DPCD registers has side-effects and some of these can cause a
problem for instance during link training. Based on this it's better to
avoid the probing quirk done before each DPCD register read, limiting
this to the monitor which requires it. Add an EDID quirk for this. Leave
the quirk enab
On Tue 25 Feb 2025 at 08:04, Doug Anderson wrote:
> Hi,
>
> On Tue, Feb 18, 2025 at 11:30 AM Jerome Brunet wrote:
>>
>> The auxiliary device creation of this driver is simple enough to
>> use the available auxiliary device creation helper.
>>
>> Use it and remove some boilerplate code.
>>
>> Sig
Reading DPCD registers has side-effects and some of these can cause a
problem for instance during link training. Based on this it's better to
avoid the probing quirk done before each DPCD register read, limiting
this to the monitor which requires it. The only known problematic
monitor is an externa
inaro-mm-...@lists.linaro.org; linux-
> ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> m...@kvack.org; wangbintian(BintianWang) ;
> yipengxiang ; liulu 00013167
> ; hanfeng 00012985
> Subject: Re: [PATCH v4 0/4] Implement dmabuf direct I/O via
> copy_file_range
&g
> Subject: [PATCH v4 0/1] drm: rcar-du: rzg2l_mipi_dsi: add MIPI DSI command
> support
>
> From: Hugo Villeneuve
>
> Hello,
> this patch series add support for sending MIPI DSI command packets to the
> Renesas RZ/G2L MIPI DSI
> driver.
>
> Tested on a custom
; baolin.w...@linux.alibaba.com; linux-me...@vger.kernel.org; dri-
>> de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; linux-
>> ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
>> m...@kvack.org; wangbintian(BintianWang) ;
>> yipengxiang ; liulu 00013167
>>
inaro-mm-...@lists.linaro.org; linux-
> ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> m...@kvack.org; wangbintian(BintianWang) ;
> yipengxiang ; liulu 00013167
> ; hanfeng 00012985
> Subject: Re: [PATCH v4 0/4] Implement dmabuf direct I/O via
> copy_file_range
&g
inaro-mm-...@lists.linaro.org; linux-
> ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> m...@kvack.org; wangbintian(BintianWang) ;
> yipengxiang ; liulu 00013167
> ; hanfeng 00012985
> Subject: Re: [PATCH v4 0/4] Implement dmabuf direct I/O via
> copy_file_range
&g
On Fri, 06 Jun 2025, Maxime Ripard wrote:
> Thanks for working on that. Your two patches (the one you sent here, and
> the one in the other subthread) look good to me. So if that works, it
> looks like we have a way forward.
Coincidentally, I just posted the first non-draft patches [1]. Thanks
fo
On Tue, May 27, 2025 at 10:40:49PM +0300, Jani Nikula wrote:
> On Tue, 27 May 2025, Maxime Ripard wrote:
> > On Tue, May 20, 2025 at 01:09:47PM +0300, Jani Nikula wrote:
> >>
> >> Maxime -
> >>
> >> I'm cutting a lot of context here. Not because I don't think it deserves
> >> an answer, but beca
On 6/5/25 04:18, Biju Das wrote:
Hi Hugo,
Thanks for the patch.
-Original Message-
From: dri-devel On Behalf Of Hugo
Villeneuve
Sent: 04 June 2025 15:53
Subject: [PATCH v4 1/1] drm: renesas: rz-du: Implement MIPI DSI host transfers
From: Hugo Villeneuve
Add support for sending
On Sat, 24 May 2025 13:48:36 +0200, Jens Glathe wrote:
> Document the x1p-42-100/x1-26-100 variants of the Thinkbook 16 G7 QOY.
>
> [1]:
> https://psref.lenovo.com/syspool/Sys/PDF/ThinkBook/ThinkBook_16_G7_QOY/ThinkBook_16_G7_QOY_Spec.pdf
>
> Signed-off-by: Jens Glathe
> ---
> Documentation/
On 6/5/2025 12:21 PM, Danilo Krummrich wrote:
> On Thu, Jun 05, 2025 at 12:09:46PM -0400, Joel Fernandes wrote:
+impl PmuLookupTable {
+fn new(pdev: &pci::Device, data: &[u8]) -> Result {
+if data.len() < 4 {
+return Err(EINVAL);
+}
+
On Thu, Jun 05, 2025 at 12:09:46PM -0400, Joel Fernandes wrote:
> >> +impl PmuLookupTable {
> >> +fn new(pdev: &pci::Device, data: &[u8]) -> Result {
> >> +if data.len() < 4 {
> >> +return Err(EINVAL);
> >> +}
> >> +
> >> +let header_len = data[1] as usize;
>
On 6/3/2025 5:15 PM, Lyude Paul wrote:
> On Tue, 2025-05-27 at 16:38 -0400, Joel Fernandes wrote:
>> Hello,
>> I split this particular patch into 3 patches:
>>
>> gpu: nova-core: vbios: Add support for FWSEC ucode extraction
>> gpu: nova-core: vbios: Add support to look up PMU table in FWSEC
>>
Hi Lyude,
>> +bios_image! {
>> +PciAt PciAtBiosImage, // PCI-AT compatible BIOS image
>> +Efi EfiBiosImage, // EFI (Extensible Firmware Interface)
>> +Nbsi NbsiBiosImage, // NBSI (Nvidia Bios System Interface)
>> +FwSecPartial FwSecBiosPartial, // FWSEC (Firmware Securi
sktop.org; linux-renesas-...@vger.kernel.org;
> linux-ker...@vger.kernel.org;
> Chris Brandt
> Subject: Re: [PATCH v4 1/1] drm: renesas: rz-du: Implement MIPI DSI host
> transfers
>
> On 6/5/25 04:18, Biju Das wrote:
> > Hi Hugo,
> >
> > Thanks for the patch.
> &g
On Wed Jun 4, 2025 at 7:23 PM JST, Danilo Krummrich wrote:
> On Wed, May 21, 2025 at 03:45:12PM +0900, Alexandre Courbot wrote:
>> +impl Chipset {
>> +/// Returns the HAL corresponding to this chipset.
>> +pub(super) fn get_fb_fal(self) -> &'static dyn FbHal {
>
> Please don't use the 'get'
On Wed Jun 4, 2025 at 7:24 PM JST, Danilo Krummrich wrote:
> On Wed, Jun 04, 2025 at 01:18:37PM +0900, Alexandre Courbot wrote:
>> On Wed Jun 4, 2025 at 6:14 AM JST, Lyude Paul wrote:
>> > On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
>> >> +const NV_PRAMIN_SIZE: u64 =
...@gmail.com; sim...@ffwll.ch
Cc: dri-devel@lists.freedesktop.org; linux-renesas-...@vger.kernel.org;
linux-ker...@vger.kernel.org; h...@hugovil.com; Chris Brandt
; Hugo Villeneuve
Subject: [PATCH v4 1/1] drm: renesas: rz-du: Implement MIPI DSI host transfers
From: Hugo Villeneuve
Add support for
Hi Hugo,
Thanks for the patch.
> -Original Message-
> From: dri-devel On Behalf Of Hugo
> Villeneuve
> Sent: 04 June 2025 15:53
> Subject: [PATCH v4 1/1] drm: renesas: rz-du: Implement MIPI DSI host transfers
>
> From: Hugo Villeneuve
>
> Add support f
On Wed, Jun 04, 2025 at 04:37:27PM +0200, Simona Vetter wrote:
> On Mon, Jun 02, 2025 at 08:28:30AM +0700, Bagas Sanjaya wrote:
> > On Sun, Jun 01, 2025 at 06:18:47PM -0400, Abdulrasaq Lawani wrote:
> > > Add an overview diagram of Linux DRM architecture for
> > > graphics and compute to introducti
On 6/2/2025 9:33 AM, Danilo Krummrich wrote:
>> +/// Try to find NPDE in the data, the NPDE is right after the PCIR.
>> +fn find_in_data(
>> +pdev: &pci::Device,
>> +data: &[u8],
>> +rom_header: &PciRomHeader,
>> +pcir: &PcirStruct,
>> +) -> Option {
>
From: Hugo Villeneuve
Hello,
this patch series add support for sending MIPI DSI command packets to the
Renesas RZ/G2L MIPI DSI driver.
Tested on a custom board with a SolidRun RZ/G2L SOM, with two different LCD
panels using the jd9365da and st7703 drivers.
Tested short and long writes.
Tested
From: Hugo Villeneuve
Add support for sending MIPI DSI command packets from the host to a
peripheral. This is required for panels that need configuration before
they accept video data.
Also for long reads to work properly, set DCS maximum return packet size
to the value of the DMA buffer size.
On Mon, Jun 02, 2025 at 08:28:30AM +0700, Bagas Sanjaya wrote:
> On Sun, Jun 01, 2025 at 06:18:47PM -0400, Abdulrasaq Lawani wrote:
> > Add an overview diagram of Linux DRM architecture for
> > graphics and compute to introduction.rst
> >
> > Signed-off-by: Abdulrasaq Lawani
> > ---
> > ...
> > d
On Wed, May 21, 2025 at 03:45:14PM +0900, Alexandre Courbot wrote:
> +impl FirmwareDmaObject {
> +/// Patch the Fwsec firmware image in `fw` to run the command `cmd`.
> +fn patch_command(&mut self, v3_desc: &FalconUCodeDescV3, cmd:
> FwsecCommand) -> Result<()> {
Same comment as on the pr
On Wed, May 21, 2025 at 03:45:13PM +0900, Alexandre Courbot wrote:
> +/// A [`DmaObject`] containing a specific microcode ready to be loaded into
> a falcon.
> +///
> +/// This is module-local and meant for sub-modules to use internally.
> +struct FirmwareDmaObject(DmaObject, PhantomData);
> +
> +
On Wed, Jun 04, 2025 at 01:18:37PM +0900, Alexandre Courbot wrote:
> On Wed Jun 4, 2025 at 6:14 AM JST, Lyude Paul wrote:
> > On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> >> +const NV_PRAMIN_SIZE: u64 = 0x10;
> >
> > Don't leave those size constants out, they're
On Wed, May 21, 2025 at 03:45:12PM +0900, Alexandre Courbot wrote:
> +impl Chipset {
> +/// Returns the HAL corresponding to this chipset.
> +pub(super) fn get_fb_fal(self) -> &'static dyn FbHal {
Please don't use the 'get' prefix here.
Also, I feel like it's a bit random to have this on
On Tue, Jun 3, 2025 at 11:05 PM Lyude Paul wrote:
>
> Not sure this makes sense - debug_assertions is supposed to be about
> assertions, we probably shouldn't try to use it for other things (especially
> since we've already got dev_dbg! here)
Yeah, we added it in `pr_debug!`, but I think we shoul
On Wed Jun 4, 2025 at 1:54 AM CEST, Alexandre Courbot wrote:
> On Wed Jun 4, 2025 at 7:53 AM JST, Benno Lossin wrote:
>> On Mon Jun 2, 2025 at 11:39 AM CEST, Danilo Krummrich wrote:
>>> On Thu, May 29, 2025 at 09:27:33AM +0200, Benno Lossin wrote:
That's also fair, but we lose the constness of
On Wed Jun 4, 2025 at 2:05 AM CEST, Alexandre Courbot wrote:
> On Wed Jun 4, 2025 at 8:02 AM JST, Benno Lossin wrote:
>> On Mon Jun 2, 2025 at 3:09 PM CEST, Alexandre Courbot wrote:
>>> On Thu May 29, 2025 at 4:27 PM JST, Benno Lossin wrote:
On Thu May 29, 2025 at 3:18 AM CEST, Alexandre Courb
On Wed Jun 4, 2025 at 6:14 AM JST, Lyude Paul wrote:
> On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
>> FWSEC-FRTS is run with the desired address of the FRTS region as
>> parameter, which we need to compute depending on some hardware
>> parameters.
>>
>> Do this in a `FbLayout` stru
On Mon Jun 2, 2025 at 9:26 PM JST, Danilo Krummrich wrote:
> On Wed, May 21, 2025 at 03:45:10PM +0900, Alexandre Courbot wrote:
>> FWSEC-FRTS is the first firmware we need to run on the GSP falcon in
>> order to initiate the GSP boot process. Introduce the structure that
>> describes it.
>>
>> Sig
On Wed Jun 4, 2025 at 6:45 AM JST, Lyude Paul wrote:
> On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
>> With all the required pieces in place, load FWSEC-FRTS onto the GSP
>> falcon, run it, and check that it successfully carved out the WPR2
>> region out of framebuffer memory.
>>
>>
On Fri May 30, 2025 at 6:30 AM JST, Timur Tabi wrote:
> On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
>
> I noticed something interesting in this change to Gpu::new().
>
>> + // Check that the WPR2 region does not already exists - if it does,
>> the GPU needs to be
>> +
On Wed Jun 4, 2025 at 6:32 AM JST, Lyude Paul wrote:
>> +unsafe fn transmute<'a, 'b, T: Sized + FromBytes>(
>> +fw: &'a DmaObject,
>> +offset: usize,
>> +) -> Result<&'b T> {
>> +if offset + core::mem::size_of::() > fw.size() {
>> +return Err(EINVAL);
>> +}
>> +if (fw.s
On Wed Jun 4, 2025 at 8:02 AM JST, Benno Lossin wrote:
> On Mon Jun 2, 2025 at 3:09 PM CEST, Alexandre Courbot wrote:
>> On Thu May 29, 2025 at 4:27 PM JST, Benno Lossin wrote:
>>> On Thu May 29, 2025 at 3:18 AM CEST, Alexandre Courbot wrote:
On Thu May 29, 2025 at 5:17 AM JST, Benno Lossin wr
On Wed Jun 4, 2025 at 7:53 AM JST, Benno Lossin wrote:
> On Mon Jun 2, 2025 at 11:39 AM CEST, Danilo Krummrich wrote:
>> On Thu, May 29, 2025 at 09:27:33AM +0200, Benno Lossin wrote:
>>> That's also fair, but we lose the constness of `next_multiple_of`, so
>>> you can't use `align_up` in a const fu
On Mon Jun 2, 2025 at 3:09 PM CEST, Alexandre Courbot wrote:
> On Thu May 29, 2025 at 4:27 PM JST, Benno Lossin wrote:
>> On Thu May 29, 2025 at 3:18 AM CEST, Alexandre Courbot wrote:
>>> On Thu May 29, 2025 at 5:17 AM JST, Benno Lossin wrote:
On Wed May 21, 2025 at 8:44 AM CEST, Alexandre Cou
On Mon Jun 2, 2025 at 11:39 AM CEST, Danilo Krummrich wrote:
> On Thu, May 29, 2025 at 09:27:33AM +0200, Benno Lossin wrote:
>> That's also fair, but we lose the constness of `next_multiple_of`, so
>> you can't use `align_up` in a const function. That might confuse people
>> and then they write the
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> With all the required pieces in place, load FWSEC-FRTS onto the GSP
> falcon, run it, and check that it successfully carved out the WPR2
> region out of framebuffer memory.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/nova
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> The FWSEC firmware needs to be extracted from the VBIOS and patched with
> the desired command, as well as the right signature. Do this so we are
> ready to load and run this firmware into the GSP falcon and create the
> FRTS region.
>
Reviewed-by: Lyude Paul
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> Some of the firmwares need to be patched at load-time with a signature.
> Add a couple of types and traits that sub-modules can use to implement
> this behavior, while ensuring that the correct kind of signature
On Tue, 2025-05-27 at 16:38 -0400, Joel Fernandes wrote:
> Hello,
> I split this particular patch into 3 patches:
>
> gpu: nova-core: vbios: Add support for FWSEC ucode extraction
> gpu: nova-core: vbios: Add support to look up PMU table in FWSEC
> gpu: nova-core: vbios: Add base support for VBIOS
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> FWSEC-FRTS is run with the desired address of the FRTS region as
> parameter, which we need to compute depending on some hardware
> parameters.
>
> Do this in a `FbLayout` structure, that will be later extended to
> describe more memory
Some comments down below (in addition to the ones that Danilo left). Mostly
nits since Danilo got to most of the good feedback :P
On Wed, 2025-05-21 at 15:45 +0900, Alexandre Courbot wrote:
> From: Joel Fernandes
>
> Add support for navigating and setting up vBIOS ucode data required for
> GSP t
On 03/06/2025 17:27, Christian König wrote:
On 6/3/25 17:00, Tvrtko Ursulin wrote:
On 03/06/2025 14:13, Maxime Ripard wrote:
Hi,
On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
On 6/2/25 15:05, Tvrtko Ursulin wrote:
On 15/05/2025 14:15, Christian König wrote:
Hey drm-mis
On 6/3/25 17:00, Tvrtko Ursulin wrote:
>
> On 03/06/2025 14:13, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
>>> On 6/2/25 15:05, Tvrtko Ursulin wrote:
On 15/05/2025 14:15, Christian König wrote:
> Hey drm-misc maintainers,
>
>>
On 6/3/25 15:13, Maxime Ripard wrote:
> Hi,
>
> On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
>> On 6/2/25 15:05, Tvrtko Ursulin wrote:
>>> On 15/05/2025 14:15, Christian König wrote:
Hey drm-misc maintainers,
can you guys please backmerge drm-next into drm-misc-n
On 6/3/25 16:28, Christoph Hellwig wrote:
> On Tue, Jun 03, 2025 at 04:18:22PM +0200, Christian König wrote:
>>> Does it matter compared to the I/O in this case?
>>
>> It unfortunately does, see the numbers on patch 3 and 4.
>
> That's kinda weird. Why does the page table lookup tage so much
> ti
On 03/06/2025 14:13, Maxime Ripard wrote:
Hi,
On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
On 6/2/25 15:05, Tvrtko Ursulin wrote:
On 15/05/2025 14:15, Christian König wrote:
Hey drm-misc maintainers,
can you guys please backmerge drm-next into drm-misc-next?
I want to
On 6/2/2025 9:33 AM, Danilo Krummrich wrote:
[...]
>> +impl PcirStruct {
>> +fn new(pdev: &pci::Device, data: &[u8]) -> Result {
>> +if data.len() < core::mem::size_of::() {
>> +dev_err!(pdev.as_ref(), "Not enough data for PcirStruct\n");
>> +return Err(EINVAL
On 6/3/25 15:19, Christoph Hellwig wrote:
> On Tue, Jun 03, 2025 at 03:14:20PM +0200, Christian König wrote:
>> On 6/3/25 15:00, Christoph Hellwig wrote:
>>> This is a really weird interface. No one has yet to explain why dmabuf
>>> is so special that we can't support direct I/O to it when we can
On 6/3/25 14:48, Tvrtko Ursulin wrote:
>
> On 03/06/2025 13:40, Christian König wrote:
>> On 6/3/25 13:30, Tvrtko Ursulin wrote:
>>>
>>> On 02/06/2025 19:00, Christian König wrote:
On 6/2/25 17:25, Tvrtko Ursulin wrote:
>
> On 02/06/2025 15:42, Christian König wrote:
>> On 6/2/25
On 6/3/25 3:47 PM, Joel Fernandes wrote:
On 6/3/2025 4:12 AM, Alexandre Courbot wrote:
Would it then make sense to make `FwSecBiosImage` public, add an `fn
fwsec_image(&self) -> &FwSecBiosImage` method and have the caller call
its methods directly (maybe renamed to `header`, `ucode` and `sigs`)?
On 6/3/2025 4:12 AM, Alexandre Courbot wrote:
> On Tue Jun 3, 2025 at 12:15 AM JST, Joel Fernandes wrote:
>> On Mon, Jun 02, 2025 at 03:33:56PM +0200, Danilo Krummrich wrote:
>>> On Wed, May 21, 2025 at 03:45:11PM +0900, Alexandre Courbot wrote:
+impl Vbios {
>>>
>>>
>>>
+pub(crat
On 6/3/25 15:00, Christoph Hellwig wrote:
> This is a really weird interface. No one has yet to explain why dmabuf
> is so special that we can't support direct I/O to it when we can support
> it to otherwise exotic mappings like PCI P2P ones.
With udmabuf you can do direct I/O, it's just ineffici
Hi,
On Mon, Jun 02, 2025 at 04:42:27PM +0200, Christian König wrote:
> On 6/2/25 15:05, Tvrtko Ursulin wrote:
> > On 15/05/2025 14:15, Christian König wrote:
> >> Hey drm-misc maintainers,
> >>
> >> can you guys please backmerge drm-next into drm-misc-next?
> >>
> >> I want to push this patch here
On 03/06/2025 13:40, Christian König wrote:
On 6/3/25 13:30, Tvrtko Ursulin wrote:
On 02/06/2025 19:00, Christian König wrote:
On 6/2/25 17:25, Tvrtko Ursulin wrote:
On 02/06/2025 15:42, Christian König wrote:
On 6/2/25 15:05, Tvrtko Ursulin wrote:
Hi,
On 15/05/2025 14:15, Christian Kö
x-me...@vger.kernel.org; dri-
> > de...@lists.freedesktop.org; linaro-mm-...@lists.linaro.org; linux-
> > ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> > m...@kvack.org; wangbintian(BintianWang) ;
> > yipengxiang ; liulu 00013167
> > ; hanfeng 00
On 6/3/25 13:30, Tvrtko Ursulin wrote:
>
> On 02/06/2025 19:00, Christian König wrote:
>> On 6/2/25 17:25, Tvrtko Ursulin wrote:
>>>
>>> On 02/06/2025 15:42, Christian König wrote:
On 6/2/25 15:05, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 15/05/2025 14:15, Christian König wrote:
>
; ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> m...@kvack.org; wangbintian(BintianWang) ;
> yipengxiang ; liulu 00013167
> ; hanfeng 00012985
> Subject: Re: [PATCH v4 1/4] fs: allow cross-FS copy_file_range for memory
> file with direct I/O
>
> On Tue, Jun 3,
; ker...@vger.kernel.org; linux-fsde...@vger.kernel.org; linux-
> m...@kvack.org; wangbintian(BintianWang) ;
> yipengxiang ; liulu 00013167
> ; hanfeng 00012985
> Subject: Re: [PATCH v4 2/4] dmabuf: Implement copy_file_range callback for
> dmabuf direct I/O prep
>
>
>
> On 6
First determine if dmabuf reads from or writes to the file.
Then call exporter's rw_file callback function.
Signed-off-by: wangtao
---
drivers/dma-buf/dma-buf.c | 32
include/linux/dma-buf.h | 16
2 files changed, 48 insertions(+)
diff --git a
Main steps to load file data into dmabuf:
1. dmabuf_fd = dmabuf_alloc(len, heap_fd)
2. vaddr = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, dmabuf_fd, 0)
3. file_fd = open(file_path, O_RDONLY)
4. read(file_fd, vaddr, len)
dmabuf's attachment/map/fence model sets VM_PFNMAP for mmap, which la
On Tue, Jun 3, 2025 at 11:53 AM wangtao wrote:
>
> Memory files can optimize copy performance via copy_file_range callbacks:
> -Compared to mmap&read: reduces GUP (get_user_pages) overhead
> -Compared to sendfile/splice: eliminates one memory copy
> -Supports dma-buf direct I/O zero-copy implement
On 02/06/2025 19:00, Christian König wrote:
On 6/2/25 17:25, Tvrtko Ursulin wrote:
On 02/06/2025 15:42, Christian König wrote:
On 6/2/25 15:05, Tvrtko Ursulin wrote:
Hi,
On 15/05/2025 14:15, Christian König wrote:
Hey drm-misc maintainers,
can you guys please backmerge drm-next into drm
Construct bio_vec from folios, then call the other file's
r/w callbacks for IO operations.
Test data shows direct I/O copy_file_range improves performance by
over 50% vs direct I/O mmap&read (2557 vs 1534).
Test data:
|32x32MB Read 1024MB |Creat-ms|Close-ms| I/O-ms|I/O-MB/s| I/O%
|--
On 6/3/25 11:52, wangtao wrote:
> First determine if dmabuf reads from or writes to the file.
> Then call exporter's rw_file callback function.
>
> Signed-off-by: wangtao
> ---
> drivers/dma-buf/dma-buf.c | 32
> include/linux/dma-buf.h | 16
First verify system_heap exporter has exclusive dmabuf access.
Build bio_vec from sgtable, then invoke target file's r/w callbacks for IO.
Outperforms buffer IO mmap/read by 250%, beats direct I/O udmabuf
copy_file_range by over 30% with initialization time significantly lower
than udmabuf.
Test d
Memory files can optimize copy performance via copy_file_range callbacks:
-Compared to mmap&read: reduces GUP (get_user_pages) overhead
-Compared to sendfile/splice: eliminates one memory copy
-Supports dma-buf direct I/O zero-copy implementation
Suggested by: Christian König
Suggested by: Amir G
On Tue Jun 3, 2025 at 12:15 AM JST, Joel Fernandes wrote:
> On Mon, Jun 02, 2025 at 03:33:56PM +0200, Danilo Krummrich wrote:
>> On Wed, May 21, 2025 at 03:45:11PM +0900, Alexandre Courbot wrote:
>> > +impl Vbios {
>>
>>
>>
>> > +pub(crate) fn fwsec_header(&self, pdev: &device::Device) ->
>
Hi Lyude, thanks for the review!
On Sat May 31, 2025 at 7:22 AM JST, Lyude Paul wrote:
>> +/// `target_mem`.
>> +///
>> +/// `sec` is set if the loaded firmware is expected to run in secure
>> mode.
>> +fn dma_wr(
>> +&self,
>> +bar: &Bar0,
>> +dma_handle:
On Mon Jun 2, 2025 at 9:06 PM JST, Danilo Krummrich wrote:
> On Wed, May 21, 2025 at 03:45:09PM +0900, Alexandre Courbot wrote:
>> Add the common Falcon code and HAL for Ampere GPUs, and instantiate the
>> GSP and SEC2 Falcons that will be required to boot the GSP.
>
> Maybe add a few more words ab
This patch provides an initialization framework for multiple Mali GPUs
by introducing a GPU support look-up table. Each entry contains, at
minimum, the architecture major version of the GPU, and may optionally
provide feature flags and register offset overrides.
Signed-off-by: Karunika Choo
---
On 6/2/25 17:25, Tvrtko Ursulin wrote:
>
> On 02/06/2025 15:42, Christian König wrote:
>> On 6/2/25 15:05, Tvrtko Ursulin wrote:
>>>
>>> Hi,
>>>
>>> On 15/05/2025 14:15, Christian König wrote:
Hey drm-misc maintainers,
can you guys please backmerge drm-next into drm-misc-next?
This patch adds GPU model name and FW binary support for Mali-G710,
Mali-G510, and Mali-G310.
Signed-off-by: Karunika Choo
---
drivers/gpu/drm/panthor/panthor_fw.c | 2 ++
drivers/gpu/drm/panthor/panthor_hw.c | 6 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/panthor/pant
On Wed, May 21, 2025 at 03:45:11PM +0900, Alexandre Courbot wrote:
> +impl Vbios {
> +pub(crate) fn fwsec_header(&self, pdev: &device::Device) ->
> Result<&FalconUCodeDescV3> {
> +self.fwsec_image.fwsec_header(pdev)
> +}
> +
> +pub(crate) fn fwsec_ucode(&self, pdev: &device:
On 02/06/2025 15:42, Christian König wrote:
On 6/2/25 15:05, Tvrtko Ursulin wrote:
Hi,
On 15/05/2025 14:15, Christian König wrote:
Hey drm-misc maintainers,
can you guys please backmerge drm-next into drm-misc-next?
I want to push this patch here but it depends on changes which are partia
On Mon, Jun 02, 2025 at 03:33:56PM +0200, Danilo Krummrich wrote:
> On Wed, May 21, 2025 at 03:45:11PM +0900, Alexandre Courbot wrote:
> > +impl Vbios {
>
>
>
> > +pub(crate) fn fwsec_header(&self, pdev: &device::Device) ->
> > Result<&FalconUCodeDescV3> {
> > +self.fwsec_image.fwse
On 6/2/25 15:05, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 15/05/2025 14:15, Christian König wrote:
>> Hey drm-misc maintainers,
>>
>> can you guys please backmerge drm-next into drm-misc-next?
>>
>> I want to push this patch here but it depends on changes which are partially
>> in drm-next and parti
1 - 100 of 5073 matches
Mail list logo
