Re: [RFC v2 1/1] fpga-region: Add generic IOCTL interface for runtime FPGA programming

[Marco Pagani <marco.pagani@linux.dev>]

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.

>> 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.
 
> Thanks,
> Yilun
> 
>> there is a match, a specific region driver can handle the enumeration
>> within the new region.
>>
>> What do you think?

Thanks,
Marco