From: Krzysztof Kozlowski <krzk@kernel.org>
To: Sam Winchenbach <sam.winchenbach@framepointer.org>
Cc: linux-kernel@vger.kernel.org, mdf@kernel.org, hao.wu@intel.com,
yilun.xu@intel.com, trix@redhat.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, michal.simek@amd.com,
linux-fpga@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Sam Winchenbach <swinchenbach@arka.org>
Subject: Re: [PATCH 1/2] dt-bindings: fpga: zynq: Document ICAP on boot
Date: Wed, 9 Apr 2025 08:03:10 +0200 [thread overview]
Message-ID: <018b15a8-4f5b-4752-b865-06608b82e7d5@kernel.org> (raw)
In-Reply-To: <2ccsnpv67gsu354uo7xe7syrxs265ncj6hl26v3cwf2dfm7hyu@ihkemyajuiag>
On 31/03/2025 15:07, Sam Winchenbach wrote:
>>> Before writing the fabric to the FPGA the driver disables the ICAP, enabling
>>> the PCAP. Once writing is complete it unconditionally disables the PCAP,
>>> enabling the ICAP. This patch just makes it so, depending on the use case,
>>> the ICAP can be enabled at boot. This will not prevent the system from being
>>> able to load a fabric through the driver. I added in this boolean so existing
>>> behavior would be maintained.
>>>
>>> Do you recommend another approach such as writing to a sysfs attribute to
>>> switch from PCAP to ICAP?
>> Not sure yet. Can't you check the status of ICAP before programming and
>> then enable it only if was enabled before?
>
> I am having a bit of difficulty understanding this so let's talk about cases
> where the ICAP is enabled/disabled -
>
> 1. When writing the fabric from the driver
> In this situation it might make sense to read the state of the ICAP
> interface when preparing the fabric, before enabling PCAP. When the write
> completes you could re-enable the ICAP if it was previously enabled.
>
> This might be outside the scope of this change - and I am not comfortable
> enough with this use-case to understand potential side effects from doing
> this. Logically it makes sense, but there may be a very specific reason that
> the ICAP must be enabled after doing a fabric load or partial
> reconfiguration.
>
> 2. When the FPGA driver loads and is probed by the DTS
> In this situation, which is covered by this patch, the FPGA is loaded by
> BootROM/FSBL but contains functionality that requires the ICAP. Unless the
> user has made modifications to the FSBL or 3rd stage bootloader there is no
> clear way to enable the ICAP interface. Checking to see if it had been
> enabled prior to loading this driver does not (in my opinion) make a lot of
> sense here.
>
> Perhaps the name of the DTS is confusing? The suffix '-on-load' was meant to
> indicate when the driver was loaded, not the fabric. Would the suffix
> '-on-probe' be more clear?
None of these two, because you refer to software. Property is fine but
you need to describe the actual state of hardware or system or entire
stack, e.g. "fpga-with-sem".
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-04-09 6:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-28 14:19 [PATCH 1/2] dt-bindings: fpga: zynq: Document ICAP on boot Sam Winchenbach
2025-03-28 14:19 ` [PATCH 2/2] fpga: zynq-fpga: Allow ICAP enable on probe Sam Winchenbach
2025-03-29 4:59 ` [PATCH 1/2] dt-bindings: fpga: zynq: Document ICAP on boot Krzysztof Kozlowski
2025-03-31 12:30 ` Sam Winchenbach
2025-03-31 12:43 ` Krzysztof Kozlowski
2025-03-31 13:07 ` Sam Winchenbach
2025-04-01 6:17 ` Krzysztof Kozlowski
2025-04-09 6:03 ` Krzysztof Kozlowski [this message]
2025-04-24 10:02 ` Xu Yilun
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=018b15a8-4f5b-4752-b865-06608b82e7d5@kernel.org \
--to=krzk@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hao.wu@intel.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mdf@kernel.org \
--cc=michal.simek@amd.com \
--cc=robh@kernel.org \
--cc=sam.winchenbach@framepointer.org \
--cc=swinchenbach@arka.org \
--cc=trix@redhat.com \
--cc=yilun.xu@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