ul" of patchsets, which is "get
GPU firmware running on Ampere/Ada"), I think let's defer the HALs
until the first patchset that needs them.
thanks,
--
John Hubbard
lue passed (which is what nova-core's register macro bitfield
> implementation currently does anyway).
>
Yes. Assuming that I'm not completely lost here, you are proposing to
simply truncate to the size of the bitfield--no panics, no warnings. And
that's perfectly fine here IMHO.
thanks,
--
John Hubbard
ady
requires -O2 optimization for *functional* correctness.
So Rust for Linux certainly can specify a certain set of build
options that are required--including options that are normally
considered optimizations.
thanks,
--
John Hubbard
.
except to satisfy paranoia
Using unsafe code everywhere (or introducing unsoundness or UB for
convenience) would defeat much of the Rust for Linux exercise.
Yes. It's only "paranoia" if the code is bug-free. So Rust itself
naturally will look "a little" paranoid, that's core to its mission. :)
thanks,
--
John Hubbard
On 9/8/25 5:53 AM, David Hildenbrand wrote:
On 08.09.25 14:25, Lorenzo Stoakes wrote:
On Sat, Sep 06, 2025 at 08:56:48AM +0200, David Hildenbrand wrote:
On 06.09.25 03:05, John Hubbard wrote:
...
Roughly, what I am thinking (limiting it to pte+pmd case) about is
the following:
I cannot get
On 9/5/25 11:56 PM, David Hildenbrand wrote:
On 06.09.25 03:05, John Hubbard wrote:
On 9/1/25 8:03 AM, David Hildenbrand wrote:
...> Well, there is a lot I dislike about record_subpages() to go back
there.
Starting with "as Willy keeps explaining, the concept of subpages do
not e
> unsigned long addr,
> }
>
> *nr += refs;
> + for (; refs; refs--)
> + *(pages++) = page++;
Hi David,
Probably a similar sentiment as Lorenzo here...the above diffs make the code
*worse* to read. In fact, I recall adding record_subpages() here long ago,
specifically to help clarify what was going on.
Now it's been returned to it's original, cryptic form.
Just my take on it, for whatever that's worth. :)
thanks,
--
John Hubbard
> folio_set_referenced(folio);
> return 1;
> }
`genmask_*` macros currently do.
>
The H:L (for example "11:9 available as u8", above) is elegant and readable.
The Rust native syntax "L..=H", much less so.
For this part of the kernel, dealing specifically with bits, feel pretty
strongly that we should go with "H:L".
thanks,
--
John Hubbard
On 9/1/25 4:55 PM, Alistair Popple wrote:
On 2025-08-30 at 09:55 +1000, John Hubbard wrote...
On 8/27/25 1:19 AM, Alistair Popple wrote:
...
+// SAFETY: No DMA allocations have been made yet
+unsafe { pdev.dma_set_mask_and_coherent(DmaMask::new::<48>())? };
Even
On 8/29/25 5:59 PM, Alexandre Courbot wrote:
On Sat Aug 30, 2025 at 8:30 AM JST, John Hubbard wrote:
On 8/25/25 9:07 PM, Alexandre Courbot wrote:
...
We only support one version of the firmware. And in the coming months,
that one version will have a different version number.
Given those
8 bits suffices for those.
So, you could leave this patch as-is, and I'll change 48 --> 52 in the
upcoming Hopper/Blackwell series. Or you can change it now.
Either way is fine, so:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
> +
> let bar = Arc::pin_init(
> pdev.iomap_region_sized::(0,
> c_str!("nova-core/bar0")),
> GFP_KERNEL,
::GSP_FW_HEAP_PARAM_CLIENT_ALLOC_SIZE;
> +/// Amount of extra WPR heap to reserve per GB of framebuffer memory, in
> bytes.
> +pub(crate) use r570_144::GSP_FW_HEAP_PARAM_SIZE_PER_GB_FB;
> +
> +/// Structure passed to the GSP bootloader, containing the framebuffer
> layout as well as the DMA
> +/// addresses of the GSP bootloader and firmware.
> +pub(crate) use r570_144::GspFwWprMeta;
thanks,
--
John Hubbard
On 8/28/25 1:44 PM, Konstantin Ryabitsev wrote:
> On Wed, Aug 27, 2025 at 02:56:26PM -0700, John Hubbard wrote:
>>> Right, b4 is supposed to be able to help with this as well, but indeed a
>>
>> It really doesn't quite, though.
>>
>> It is true that &quo
On 8/28/25 4:13 AM, Alexandre Courbot wrote:
> On Thu Aug 28, 2025 at 1:01 PM JST, John Hubbard wrote:
>> On 8/25/25 9:07 PM, Alexandre Courbot wrote:
...
>>/// Level 1 page table(s) whose entries contain DMA addresses of
>> level 2 pages.
>
> Looking good. B
On 8/28/25 12:19 AM, Alexandre Courbot wrote:
> On Wed Aug 27, 2025 at 11:29 AM JST, John Hubbard wrote:
>> On 8/25/25 9:07 PM, Alexandre Courbot wrote:
>> ...
>>> +let ucode_signed = {
>>
>> This ucode_signed variable is misnamed...
&g
e?)
>
> Not sure what you mean by wrong bounds here? Do you mean what if the
> header data is incorrect?
Yes, that's what I meant. And I'm mainly trying to get some perspective
about what kinds of checking we should be doing.
In this case, it seems that we don't actually need anything more than
what you already have, so we're all good here.
thanks,
--
John Hubbard
E
> tristate "Nova Core GPU driver"
> + depends on 64BIT
Yes!
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
that we would attempt 32-bit support in
Nova.
So Nova should definitely depend upon 64-bit configs.
thanks,
--
John Hubbard
a_core.rs | 1 +
> drivers/gpu/nova-core/nvfw.rs | 3 +++
> drivers/gpu/nova-core/nvfw/r570_144.rs | 29
> +
> drivers/gpu/nova-core/nvfw/r570_144_bindings.rs | 1 +
> 4 files changed, 34 insertions(+)
>
Reviewed-b
l. The newer firmware is expected to iron out some
> of the inelegances of 570.144, notably related to packaging.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/nova-core/firmware.rs | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: John Hubbard
--git a/drivers/gpu/nova-core/gsp.rs b/drivers/gpu/nova-core/gsp.rs
> new file mode 100644
> index
> ..a0e7ec5f6c9c959d57540b3ebf4b782f2e002b08
> --- /dev/null
> +++ b/drivers/gpu/nova-core/gsp.rs
> @@ -0,0 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +pub(crate) const GSP_PAGE_SHIFT: usize = 12;
> +pub(crate) const GSP_PAGE_SIZE: usize = 1 << GSP_PAGE_SHIFT;
> diff --git a/drivers/gpu/nova-core/nova_core.rs
> b/drivers/gpu/nova-core/nova_core.rs
> index
> cb2bbb30cba142265b354c9acf70349a6e40759e..fffcaee2249fe6cd7f55a7291c1e44be42e791d9
> 100644
> --- a/drivers/gpu/nova-core/nova_core.rs
> +++ b/drivers/gpu/nova-core/nova_core.rs
> @@ -9,6 +9,7 @@
> mod firmware;
> mod gfw;
> mod gpu;
> +mod gsp;
> mod regs;
> mod util;
> mod vbios;
>
thanks,
--
John Hubbard
drivers/gpu/nova-core/firmware/riscv.rs | 89
> +
> 2 files changed, 94 insertions(+), 2 deletions(-)
>
I've once again failed to find any problems with the code itself, and
have instead listed one or two trivial documentation suggestions,
below. :)
Re
On 8/27/25 1:39 AM, Alexandre Courbot wrote:
> On Wed Aug 27, 2025 at 9:29 AM JST, John Hubbard wrote:
>> On 8/25/25 9:07 PM, Alexandre Courbot wrote:
>> ...
>> But the point is that the admin can be made simpler for the reviewers--even
>> those of us who know exactl
On 8/27/25 1:47 AM, Alexandre Courbot wrote:
> On Wed Aug 27, 2025 at 10:34 AM JST, John Hubbard wrote:
>
>>> +/// Returns the data payload of the firmware, or `None` if the data
>>> range is out of bounds of
>>> +/// the firmware image.
>&
dev_info!(
> +self.dev,
> +"GSP RPC: receive: seq# {}, function=0x{:x} ({}),
> length=0x{:x}\n",
> +rpc_header.sequence,
> +rpc_header.function,
> +decode_gsp_function(rpc_header.function),
> +rpc_header.length,
> +);
Here also: please use dev_dbg!() for this one.
thanks,
--
John Hubbard
Params {
> +self.brom_params.clone()
> +}
> +
> +fn boot_addr(&self) -> u32 {
> +self.imem_load_target.src_start
> +}
> +}
> +
> +impl Deref for BooterFirmware {
> + type Target = DmaObject;
> +
> +fn deref(&self) -> &Self::Target {
> +&self.ucode.0
> +}
> +}
OK, so this allows &BooterFirmware to be used where &DmaObject is expected,
but it's not immediately obvious that BooterFirmware derefs to its internal
DMA object. It feels too clever...
Could we do something a little more obvious instead? Sort of like this:
impl BooterFirmware {
pub(crate) fn dma_object(&self) -> &DmaObject {
&self.ucode.0
}
}
...
I'm out of time today, will work on the other half of the series tomorrow.
thanks,
--
John Hubbard
gt; +let fw_start = self.hdr.data_offset as usize;
> +let fw_size = self.hdr.data_size as usize;
> +
> + self.fw.get(fw_start..fw_start + fw_size)
This worries me a bit, because we never checked that these bounds
are reasonable: within the range of the firmware, and not overflowing
(.checked_add() for example), that sort of thing.
Thoughts?
> +}
> +}
> +
> pub(crate) struct ModInfoBuilder usize>(firmware::ModInfoBuilder);
>
> impl ModInfoBuilder {
>
thanks,
--
John Hubbard
afe {
> core::ptr::read_unaligned(bytes.as_ptr().cast::()) })
> +} else {
> +None
> +}
> +}
> }
>
> macro_rules! impl_frombytes {
>
I'm unable to find anything wrong with the code itself, and the above are just
tiny nits, so whether or not you apply either or both of the above suggestions,
please feel free to add:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
ich are not actually necessary for git am (although they
might be for actual testing).
But the point is that the admin can be made simpler for the reviewers--even
those of us who know exactly what you're up to. And we should keep
that in mind, especially because there are many more of these situations
coming soon.
thanks,
--
John Hubbard
a/drivers/gpu/nova-core/nova_core.rs
+++ b/drivers/gpu/nova-core/nova_core.rs
@@ -2,6 +2,7 @@
//! Nova Core GPU Driver
+mod bitstruct;
mod dma;
mod driver;
mod falcon;
thanks,
--
John Hubbard
On 7/25/25 9:14 AM, Daniel Almeida wrote:
Hi Alex. Thank you and John for working on this in general. It will be useful
for the whole ecosystem! :)
On 18 Jul 2025, at 04:26, Alexandre Courbot wrote:
From: John Hubbard
There is only one top-level macro in this file at the moment, but the
that.
thanks,
--
John Hubbard
ver probe function?
At this point, we are only getting things up to a certain very early
stage. And so we have to reset like this in order to try again.
But I'm not sure that will be the case, once we have more code in
place to go further.
So maybe hold off on this for a few weeks or so?
thanks,
--
John Hubbard
On 6/12/25 1:05 PM, Boqun Feng wrote:
> On Thu, Jun 12, 2025 at 01:00:12PM -0700, John Hubbard wrote:
>> On 6/12/25 8:07 AM, Boqun Feng wrote:
>>> On Thu, Jun 12, 2025 at 11:01:32PM +0900, Alexandre Courbot wrote:
>> ...
>>>> +#[inline(always)
! :)
>
> ? It's much harder to pass an invalid alignment with this.
Hopefully we can address argument validation without blowing up
the usual naming conventions.
thanks,
--
John Hubbard
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'
lar, the gpu/nova*, gpu/drm/nova* drivers,
can *leave behind*.
DRM may have had ${reasons} for this approach, but this nova effort is
rebuilding from the ground up. So we should avoid just blindly following
this aspect of the original DRM design.
thanks,
--
John Hubbard
On 2/19/25 3:13 PM, Daniel Almeida wrote:
On 19 Feb 2025, at 17:23, Dave Airlie wrote:
On Thu, 20 Feb 2025 at 06:22, John Hubbard wrote:
On 2/19/25 4:51 AM, Alexandre Courbot wrote:
Yes, that looks like the optimal way to do this actually. It also
doesn't introduce any overhead a
to find a better naming. high() and low() might be enough?
Or are there other suggestions?
Maybe use "32" instead of "half":
.high_32() / .low_32()
.upper_32() / .lower_32()
thanks,
--
John Hubbard
fields)>
The .high_half() and .low_half() approach matches that very closely.
And it's simpler to read than the SplitU64 API, without losing anything
we need, right?
thanks,
--
John Hubbard
ring),
and an Ampere GPU, and traced through actually loading NovaCore, and it
behaves as described above.
thanks,
--
John Hubbard
On 2/1/25 5:52 AM, Danilo Krummrich wrote:
On Fri, Jan 31, 2025 at 08:01:00PM -0800, John Hubbard wrote:
On 1/31/25 2:04 PM, Danilo Krummrich wrote:
...
+/// Enum representation of the GPU generation.
+#[derive(Debug)]
+pub(crate) enum CardType {
+/// Turing
+TU100 = 0x160
onfig
index 44c9ef1435a2..5df981920a94 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -39,6 +39,7 @@ source "drivers/gpu/vga/Kconfig"
source "drivers/gpu/host1x/Kconfig"
source "drivers/gpu/ipu-v3/Kconfig"
+source "drivers/gpu/nova-core/Kconfig"
source "drivers/gpu/drm/Kconfig"
base-commit: 69b8923f5003664e3ffef102e7edfa2abdcf
I'm always grateful when anyone uses "git format-patch --base", it makes
life simpler.
thanks,
--
John Hubbard
d long gup_flags)
if ((gup_flags & FOLL_LONGTERM) && vma_is_fsdax(vma))
return -EOPNOTSUPP;
+ if ((gup_flags & FOLL_SPLIT_PMD) && is_vm_hugetlb_page(vma))
+ return -EOPNOTSUPP;
+
This seems correct by inspection, as one cannot split a h
hat support
specific operations are accepted in foo().
(Rust at the language level looks a lot more like a replacement for C++,
than a replacement for C, imho. By which I mean, it has lots of goodies
for expressing things, built right into the language.)
thanks,
--
John Hubbard
On 7/11/24 8:28 AM, Mina Almasry wrote:
On Wed, Jul 10, 2024 at 5:44 PM John Hubbard wrote:
On 7/9/24 5:17 PM, Mina Almasry wrote:
...
diff --git a/tools/testing/selftests/net/Makefile
b/tools/testing/selftests/net/Makefile
index bc3925200637c..39420a6e86b7f 100644
--- a/tools/testing
.sh lib.sh net_helper.sh setup_loopback.sh setup_veth.sh
@@ -104,6 +109,10 @@ TEST_INCLUDES := forwarding/lib.sh
include ../lib.mk
+# YNL build
+YNL_GENS := netdev
+include ynl.mk
This seems to be missing a rule to generate ynl.mk, right?
thanks,
--
John Hubbard
NVIDIA
using the
same nomenclature as the drm-vm-bind-async.rst.
Hi Thomas,
As requested, for the pin_user_pages() aspects (the MMU notifier
registration case), please feel free to add:
Acked-by: John Hubbard
v2:
- s/gvm/gpu_vm/g (Rodrigo Vivi)
- Clarify the userptr seqlock with a pointer to mm
completeness: s/mapcount/refcount/ :)
whew, you had me going there! Now it all adds up. :)
thanks,
--
John Hubbard
NVIDIA
include/linux/mm.h | 27 ---
mm/gup.c | 10 +-
mm/huge_memory.c | 2 +-
mm/hugetlb.c | 7 ---
4 files changed, 34 insertions(+), 12 deletions(-)
Looks good,
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
diff -
rned
about, but it looks quite helpful here). And also, user space will
need to open both /dev/dri/* and /dev/accel/* nodes, if it needs
access to anything live objects that drivers/accel owns.
thanks,
--
John Hubbard
NVIDIA
some point, we're going to make this all work with
file-backed memory, which will *definitely* not be discardable--I
realize that we're not there yet, of course.
But here, it's reasonable to commit to just retrying indefinitely,
really. Memory should eventually show up. And if it doesn't, then
restarting the machine is better than corrupting data, generally.
thanks,
--
John Hubbard
NVIDIA
ring the comments into alignment with the code.
* I don't think memset deals properly with a zero length input arg, so
it's probably better to return 0, before that point.
thanks,
--
John Hubbard
NVIDIA
- if (args->start < args->vma->vm_start ||
- args->
ith this:
nr_foll_pin_acquired
nr_foll_pin_released
...and those should normally be equal to each other when "at rest".
I hope this is/was run, just to be sure?
thanks,
--
John Hubbard
NVIDIA
the many things to monitor, the FOLL_PIN counts
in /proc/vmstat are especially helpful, whenever making changes to code
that deals with this:
nr_foll_pin_acquired
nr_foll_pin_released
...and those should normally be equal to each other when "at rest".
On 1/20/22 6:12 AM, Christoph Hellwig wrote:
On Tue, Jan 11, 2022 at 12:17:18AM -0800, John Hubbard wrote:
Zooming in on the pinning aspect for a moment: last time I attempted to
convert O_DIRECT callers from gup to pup, I recall wanting very much to
record, in each bio_vec, whether these pages
And of course, you're signing for another huge naming debate with Linus
if you go with the "cool" name here. :)
thanks,
--
John Hubbard
NVIDIA
;t need to worry so much about
providing first-class support for non-ODP setups.
I've got to drag my brain into 2021+! :)
thanks,
--
John Hubbard
NVIDIA
block migration from happening eg if the CPU touches it
later or something.
OK. I just want to avoid creating any API-level assumptions that dma_buf_pin()
necessarily implies or requires migrating to host memory.
thanks,
--
John Hubbard
NVIDIA
ory in vidmem.
So I think we don't want to rule out that behavior, right? Or is the
thinking more like, "you're lucky that this old non-ODP setup works at
all, and we'll make it work by routing through host/cpu memory, but it
will be slow"?
thanks,
--
John Hubbard
NVIDIA
t we're here, if you drop this hunk then
it will make merging easier, I think.
[1] https://lore.kernel.org/r/20210813044133.1536842-4-jhubb...@nvidia.com
thanks,
--
John Hubbard
NVIDIA
he the CPU, in that regard. My example was just one,
out
of a vast pool of possible behaviors.
thanks,
--
John Hubbard
NVIDIA
, and only a tiny bit of (reduced!) data comes back
to the CPU. In that case, freeing the physical page on the CPU is actually the
best decision for the OS to make (if the OS is sufficiently prescient).
thanks,
--
John Hubbard
NVIDIA
ose programming on devices that
have GPU-like memory models.
thanks,
--
John Hubbard
NVIDIA
On 3/30/21 8:56 PM, John Hubbard wrote:
On 3/30/21 3:56 PM, Alistair Popple wrote:
...
+1 for renaming "munlock*" items to "mlock*", where applicable. good grief.
At least the situation was weird enough to prompt further investigation :)
Renaming to mlock* doesn&#
as there
is only one caller of try_to_munlock.
- Alistair
No objections here. :)
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
unlock*" items to "mlock*", where applicable. good grief.
Although, it seems reasonable to tack such renaming patches onto the tail end
of this series. But whatever works.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-dev
ng in
^FOLL_LONGTERM
ZONE_MOVEABLE before they're migrated) is still being worked on. So
not big benefits yet.
Yes. Great write-up, that's very clear, and it's exactly where we're at.
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
Cc: John Hubbard
Signed-
ut we can forcefully break this whenever we feel like by revoking
the page, moving it, and then reinstating the gpu pte again and let it
continue.
Oh yes, that's true.
If that's no possible then what we need here instead is an mlock() type of
thing I think.
No need for that, then.
asily write programs that do a long series of atomic
operations.
Such a program would be a little weird, but it's hard to rule out.
- long term pin: the page cannot be moved, all migration must fail.
Also this will have an impact on COW behaviour for fork (but not sure
where those patches ar
in, but not a refcount
pin.)
It's a nice clean design point that we need to preserve, and fortunately it
doesn't conflict with anything I'm seeing here. But I want to say this out
loud because I see some doubt about it creeping into the discussion.
thanks,
--
John Hubbard
NVIDIA
Obviously not worth spinning another version for that, as it is still readable
as-is. Just mentioning it for the sake of pointless perfectionism, and in case
someone ever wonders why it was missed during a review. :) Either way, feel free
to add:
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NV
way to use this solution here for peer-to-peer. So I'm glad to see that
so far you're not ruling out the pinning option.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
about the future of pinning to vidmem,
for this? It would allow a huge group of older GPUs and NICs and such to
do p2p with this approach, and it seems like a natural next step, right?
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dm_mr.close()
+
+
+def check_dmabuf_support(unit=0):
+"""
+Check if dma-buf allocation is supported by the system.
+Skip the test on failure.
+"""
+device_num = 128 + unit
+try:
+DmaBuf(1, unit=unit)
unit?? Th
spelling. "Coyyntext" just doesn't sound as good. :)
:param num: Size of initial collection
:return: A random legal value for MR flags
"""
thanks,
--
John Hubbard
NVIDIA
___
dri-devel
ly, and I'm not
seeing a pud_mkhugespecial anywhere. So not sure this works, but probably
just me missing something again.
It means ioremap can't create an IO page PUD, it has to be broken up.
Does ioremap even create anything larger than PTEs?
From my reading, yes. See ioremap_try_hug
age, get_futex_key requires a
* get_user_pages_fast_only implementation that can pin pages. Thus it's still
* useful to have gup_huge_pmd even if we can't operate on ptes.
*/
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dr
/O RESET_REG.
To reproduce:
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml # job file is attached in this email
bin/lkp run job.yaml
Thanks,
oliver.s...@intel.com
thanks,
--
John Hubbard
NVIDIA
___
On 11/1/20 2:30 AM, Daniel Vetter wrote:
On Sun, Nov 1, 2020 at 6:22 AM John Hubbard wrote:
On 10/31/20 7:45 AM, Daniel Vetter wrote:
On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote:
On 10/30/20 3:08 AM, Daniel Vetter wrote:
...
By removing this check from this location, and changing
On 10/31/20 7:45 AM, Daniel Vetter wrote:
On Sat, Oct 31, 2020 at 3:55 AM John Hubbard wrote:
On 10/30/20 3:08 AM, Daniel Vetter wrote:
...
By removing this check from this location, and changing from
pin_user_pages_locked() to pin_user_pages_fast(), I *think* we end up
losing the check
Cc: Jason Gunthorpe
Cc: Kees Cook
Cc: Dan Williams
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Arnd Bergmann
Cc:
below about this:
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Gliss
ere to find the remaining patches:
https://lore.kernel.org/dri-devel/1602799340-138152-1-git-send-email-jianxin.xi...@intel.com/
thanks,
--
John Hubbard
NVIDIA
v5:
* Fix a few warnings reported by kernel test robot:
- no previous prototype for function 'ib_umem_dmabuf_release
less than
ret == nr_frames. And the whole partially pinned region idea turns out
to be just not useful for almost everyone, from what I recall of the gup/pup
call sites. So I wonder if we should just have get_vaddr_frames do the
cleanup here and return -EFAULT, if ret != nr_frames ?
thanks,
--
John H
On 10/9/20 12:59 AM, Daniel Vetter wrote:
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc
: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
--
v2: Use
ds like a clumsy
API design to *disable*, right?). And there is no hint about the scope.
And it *could* be so much more readable like this:
dev_access_enable(DEV_ACCESS_THIS_THREAD);
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
d
On 10/9/20 12:33 AM, Christian König wrote:
Am 08.10.20 um 23:49 schrieb John Hubbard:
On 10/8/20 4:23 AM, Christian König wrote:
...
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 3d69e51f3e4d..c9d5f1a38af3 100644
--- a/drivers/gpu/drm
wrong, as it was already done within
vma_set_file().
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
something I'm sorta new to, so a newbie question:
is it possible for the same pte to already be there, ever? If so, we
be stuck in an infinite loop here. I'm sure that's not the case, but
it's not yet obvious to me why it's impossible. Resource reservations
maybe?
thanks,
horpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.o
On 10/7/20 2:32 PM, Daniel Vetter wrote:
On Wed, Oct 7, 2020 at 10:33 PM John Hubbard wrote:
On 10/7/20 9:44 AM, Daniel Vetter wrote:
...
@@ -398,15 +399,11 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr-&
pull the pup path out from the
mmap_sem critical section as suggested by Jason.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: Mauro Carvalho Chehab
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kar
On 10/7/20 9:44 AM, Daniel Vetter wrote:
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker
: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/gpu/drm/exynos
patch 1: you can further simplify by using
unpin_user_pages_dirty_lock().
list_del(&userptr->job_node);
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/gpu/drm/exynos
On 10/3/20 2:45 AM, Daniel Vetter wrote:
On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote:
On 10/2/20 10:53 AM, Daniel Vetter wrote:
For $reasons I've stumbled over this code and I'm not sure the change
to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
convert
think it's really good that you've brought
this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.
thanks,
--
John Hubbard
NVIDIA
There is already a dax specific check (added in b7f0554a56f2 ("mm:
fail get_vaddr_frames() for filesystem-dax mappings"
1 - 100 of 739 matches
Mail list logo
