From: Jason Gunthorpe <jgg@nvidia.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
anshuman.gupta@intel.com, alexander.usyskin@intel.com,
gregkh@linuxfoundation.org, daniele.ceraolospurio@intel.com
Subject: Re: [RFC 9/9] {fwctl,drm}/xe/pcode: Introduce xe_pcode_fwctl
Date: Wed, 7 May 2025 19:04:44 -0300 [thread overview]
Message-ID: <20250507220444.GA232705@nvidia.com> (raw)
In-Reply-To: <aBu5O5odAKaxhhym@intel.com>
On Wed, May 07, 2025 at 03:49:15PM -0400, Rodrigo Vivi wrote:
> One last thing since I have your attention here. Was any time in the previous
> fwctl discussions talked about the possibility of some extra usages for like
> FW flashing or in-field-repair/tests where big data needs to filled bypassing
> lockdown mode?
For FW flash I do suggest you try to use devlink's firmware flashing
interface. I think it would be really great if that could become a
cross-subsystem standard in Linux.
If that isn't going to work out then yes I would say fwctl should be
considered for flashing.
Saeed's original version had a "big data" memory pinned DMA capable
interface as well. With justification it could come into the fwctl
version. I'm not against it, but mindful that it widens what is
possible by quite a bit.
But you might not need something like that just for flash. Some
internal improvement kernel side to allow streaming from large
user-space RPC buffers instead of a single alloc and copy would be
sufficient..
Jason
next prev parent reply other threads:[~2025-05-07 22:05 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 16:09 [RFC 0/9] Introducing firmware late binding Badal Nilawar
2025-04-29 16:09 ` [RFC 1/9] mei: bus: add mei_cldev_mtu interface Badal Nilawar
2025-04-29 16:09 ` [RFC 2/9] mei: late_bind: add late binding component driver Badal Nilawar
2025-05-07 22:42 ` Daniele Ceraolo Spurio
2025-05-08 5:41 ` Usyskin, Alexander
2025-06-03 12:01 ` Nilawar, Badal
2025-04-29 16:09 ` [RFC 3/9] drm/xe/late_bind_fw: Introducing late_bind_fw Badal Nilawar
2025-05-07 21:38 ` Daniele Ceraolo Spurio
2025-06-03 13:52 ` Nilawar, Badal
2025-04-29 16:09 ` [RFC 4/9] drm/xe/xe_late_bind_fw: Initialize late binding firmware Badal Nilawar
2025-05-07 23:11 ` Daniele Ceraolo Spurio
2025-06-03 13:57 ` Nilawar, Badal
2025-04-29 16:09 ` [RFC 5/9] drm/xe/xe_late_bind_fw: Load " Badal Nilawar
2025-05-07 23:44 ` Daniele Ceraolo Spurio
2025-06-04 5:36 ` Nilawar, Badal
2025-04-29 16:09 ` [RFC 6/9] drm/xe/xe_late_bind_fw: Reload late binding fw in rpm resume Badal Nilawar
2025-04-29 16:09 ` [RFC 7/9] drm/xe/xe_late_bind_fw: Reload late binding fw in S2Idle/S3 resume Badal Nilawar
2025-04-29 16:09 ` [RFC 8/9] drm/xe/xe_late_bind_fw: Introduce debug fs node to disable late binding Badal Nilawar
2025-04-29 16:09 ` [RFC 9/9] {fwctl,drm}/xe/pcode: Introduce xe_pcode_fwctl Badal Nilawar
2025-05-01 15:44 ` Rodrigo Vivi
2025-05-06 18:13 ` Jason Gunthorpe
2025-05-07 19:49 ` Rodrigo Vivi
2025-05-07 22:04 ` Jason Gunthorpe [this message]
2025-08-22 19:33 ` Rodrigo Vivi
2025-08-28 12:48 ` Jason Gunthorpe
2025-06-06 13:47 ` Nilawar, Badal
2025-06-06 13:45 ` Nilawar, Badal
2025-06-30 22:01 ` Rodrigo Vivi
2025-06-30 22:45 ` Jason Gunthorpe
2025-04-29 16:13 ` ✓ CI.Patch_applied: success for Introducing firmware late binding (rev2) Patchwork
2025-04-29 16:14 ` ✗ CI.checkpatch: warning " Patchwork
2025-04-29 16:15 ` ✓ CI.KUnit: success " Patchwork
2025-04-29 16:23 ` ✓ CI.Build: " Patchwork
2025-04-29 16:26 ` ✗ CI.Hooks: failure " Patchwork
2025-04-29 16:27 ` ✗ CI.checksparse: warning " Patchwork
2025-04-29 19:02 ` ✗ Xe.CI.Full: failure " Patchwork
2025-04-30 11:47 ` [RFC 0/9] Introducing firmware late binding Jani Nikula
2025-05-06 7:53 ` ✗ Xe.CI.BAT: failure for Introducing firmware late binding (rev2) Patchwork
-- strict thread matches above, loose matches on Subject: below --
2025-04-29 7:37 [RFC 0/9] Introducing firmware late binding Badal Nilawar
2025-04-29 7:38 ` [RFC 9/9] {fwctl,drm}/xe/pcode: Introduce xe_pcode_fwctl Badal Nilawar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250507220444.GA232705@nvidia.com \
--to=jgg@nvidia.com \
--cc=alexander.usyskin@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=badal.nilawar@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).