On 2025-03-01 10:27, Xu Yilun wrote: > On Mon, Feb 17, 2025 at 04:18:36PM +0100, Marco Pagani wrote: >> >> >> On 06/02/25 07:04, Xu Yilun wrote: >>>>>> I'm currently working on an RFC to propose a rework of the fpga >>>>>> subsystem in order to make it more aligned with the device model. One of >>>>>> the ideas I'm experimenting with is having a bus (struct bus_type) for >>>>>> fpga regions (devices) so that we can have region drivers that could >>>>>> handle internal device enumeration/management whenever a new region is >>>>>> configured on the fabric. Does this make sense in your opinions? >>>>> >>>>> mm.. I didn't fully understand the need to have a region driver, what's >>>>> the issue to solve? >>>>> >>>> >>>> Sorry for the late reply. The general idea is to handle regions in a way >>>> that is more aligned with the device model without having to resort to >>>> extra ops and additional devices. >>>> >>>> Having an fpga bus would allow us to handle enumeration using proper >>>> region drivers (in the device model sense of the term, i.e., struct >>>> device_driver) instead of derived region devices. >>>> >>>> On second thought, I think having a reconfiguration interface at the >>>> fpga manager level is sounder than having it at the region level (one >>>> for each region). >>> >>> I don't think so. A firmware image may contain enumeration info, e.g. >>> of-fpga-region. And I think the fpga-region should parse these >>> enumeration info rather than fpga manager. fpga manager should only deal >>> with content writing stuff and not be exposed to user. >> >> I agree with that. In my proposal, the fpga manager should be >> responsible only for writing the image into the configuration memory >> and allocating region devices. In-region enumeration should be handled by >> the region drivers. >> >> My worry with having one reconfiguration interface for each region is >> that it does not reflect how the hardware works. To my knowledge, all >> major FPGA implementations use a DMA engine (controlled by the fpga >> manager) that performs the reconfiguration through a single port. So, >> having one interface per region might be conceptually confusing and give >> the impression that it is possible to configure regions independently in >> parallel. > > One interface per region means the regions could be independently > reprogrammed, i.e. reprogramming of one region won't affect the working > of another region. But they don't have to be reprogrammed in parallel. > If it cannot be reprogrammed now, the interface call could fail. Good point. However, I still have some other practical concerns. To the best of my knowledge, reconfigurable images/bitstreams are statically built for a specific reconfigurable region in current FPGA implementations. So, what should happen if the user feeds the wrong image (e.g., an image targeting another region) into a reconfigurable region programming interface? I don't think the fpga manager could and should detect these mistakes since the kernel has no visibility of the FPGA configuration memory. >>>> With that in place, the fpga manager could request a firmware image, >>>> parse it, write the content into the fpga configuration memory, and then >>>> instantiate the region devices and add them to its fpga bus. Then, if >>> >>> I think an fpga-region is always there no matter it is cleared, being >>> reprogrammed, or working. So I don't think an fpga-region needs to be >>> re-instantated. The sub devices inside fpga-region needs >>> re-instantating. That's also why I'm hesitating to fpga bus. >> >> I think one of the issues with the current subsystem architecture is >> that it coalesces two cases: full and partial images. With partial >> images, it makes sense to keep the region devices and rerun the internal >> enumeration. With full images, I believe it makes sense to clear and >> reallocate new devices to set a new region tree. > > MM.. I don't actually understand what's the fundamental differences > between full & partial. If a full region supports full & partial > reconfiguration, the full region contains partial regions as > sub-devices. The partial reconfiguration reallocates it sub-devices and > won't change partial region itself. The full reconfiguration also > reallocates it sub-devices including partial regions, and won't change > full region itself. What I had in mind was re-instating a new region device in case of partial reconfiguration to re-trigger the enumeration by a region driver of the devices hosted in the region. At this point, I believe I should send an RFC to have something concrete to discuss. Unfortunately, it may take me some time due to a job change. Thanks, Marco
