All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Cc: hao.wu@intel.com, yilun.xu@intel.com, russell.h.weight@intel.com,
	basheer.ahmed.muddebihal@intel.com, trix@redhat.com,
	mdf@kernel.org, linux-fpga@vger.kernel.org,
	linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	tianfei.zhang@intel.com, corbet@lwn.net,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-serial <linux-serial@vger.kernel.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	geert+renesas@glider.be,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	niklas.soderlund+renesas@ragnatech.se, macro@orcam.me.uk,
	johan@kernel.org, Lukas Wunner <lukas@wunner.de>,
	marpagan@redhat.com
Subject: Re: [PATCH v4 1/4] Documentation: fpga: dfl: Add documentation for DFHv1
Date: Fri, 21 Oct 2022 11:28:58 +0300 (EEST)	[thread overview]
Message-ID: <d265dae0-fe4b-8ac0-fb9e-2a7345b279a2@linux.intel.com> (raw)
In-Reply-To: <20221020212610.697729-2-matthew.gerlach@linux.intel.com>

On Thu, 20 Oct 2022, matthew.gerlach@linux.intel.com wrote:

> From: Matthew Gerlach <matthew.gerlach@linux.intel.com>
> 
> Add documentation describing the extensions provided by Version
> 1 of the Device Feature Header (DFHv1).
> 
> Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
> ---
> v4: Remove marketing speak and separate v0 and v1 descriptions.
>     Fix errors reported by "make htmldocs".
> 
> v3: no change
> 
> v2: s/GUILD/GUID/
>     add picture
> ---
>  Documentation/fpga/dfl.rst | 96 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)
> 
> diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst
> index 15b670926084..12365be435a8 100644
> --- a/Documentation/fpga/dfl.rst
> +++ b/Documentation/fpga/dfl.rst
> @@ -561,6 +561,102 @@ new DFL feature via UIO direct access, its feature id should be added to the
>  driver's id_table.
>  
>  
> +Device Feature Header - Version 0
> +===========================================
> +The format of Version 0 of a Device Feature Header (DFH) is shown below::
> +
> +    +-----------------------------------------------------------------------+
> +    |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 VER 12|11 ID 0| 0x00
> +    +-----------------------------------------------------------------------+
> +    |63                                 GUID_L                             0| 0x08
> +    +-----------------------------------------------------------------------+
> +    |63                                 GUID_H                             0| 0x10
> +    +-----------------------------------------------------------------------+
> +
> +Offset 0x00
> +Type - The type of DFH (e.g. FME, AFU, or private feature).
> +DFH VER - The version of the DFH.
> +Rsvd - Currently unused.
> +EOL - Set if this DFH is the end of the Device Feature List (DFL).
> +Next - The offset of the next DFH in the DFL from the start of the DFH.
> +If EOL is set, Next refers to size of mmio for last feature in the list.
> +ID - If Type field is 'private feature', then ID of the private feature.
> +
> +Offset 0x08
> +GUID_L - Least significant 64 bits of a 128 bit Globally Unique Identifier
> +if Type is FME or AFU.
> +
> +Offset 0x10
> +GUID_H - Most significant 64 bits of a 128 bit Globally Unique Identifier
> +if Type is FME or AFU.
> +
> +
> +Device Feature Header - Version 1
> +===========================================

While this is structurally better than the previous one. I'd still include
at least one paragraph about the purpose. Something along these lines 
(picked from v3 + edited the marketing speak/v0 compare away from it):

Version 1 of the Device Feature Header (DFHv1) provides flexibility and 
extensibility to hardware designs using Device Feature Lists. It is a
standardized mechanism for features to describe parameters/capabilities to 
software.

With DFHv1:
* GUID is mandatory for all types
* The register space of the feature is decoupled from the location of the DFH
* A list of parameter values associates to a particular feature.

After that, the header itself makes much more sense already.

> +The format of Version 1 of a Device Feature Header (DFH) is shown below::
> +
> +    +-----------------------------------------------------------------------+
> +    |63 Type 60|59 DFH VER 52|51 Rsvd 41|40 EOL|39 Next 16|15 VER 12|11 ID 0| 0x00
> +    +-----------------------------------------------------------------------+
> +    |63                                 GUID_L                             0| 0x08
> +    +-----------------------------------------------------------------------+
> +    |63                                 GUID_H                             0| 0x10
> +    +-----------------------------------------------------------------------+
> +    |63                 Address/Offset                            1|  Rel  0| 0x18

Should this mention it's addr/offs of registers? As is it's bit hard to 
figure out from the diagram w/o the extra description. I think you have 
plenty of space for adding that extra bit of info.

> +    +-----------------------------------------------------------------------+
> +    |63        Reg Size       32|Params 31|30 Group    16|15 Instance      0| 0x20
> +    +-----------------------------------------------------------------------+
> +    |63 Next      34|RSV33|EOP32|31 Param Version 16|15 Param ID           0| 0x28
> +    +-----------------------------------------------------------------------+
> +    |63                 Parameter Data                                     0| 0x30
> +    +-----------------------------------------------------------------------+
> +
> +                                  ...
> +
> +    +-----------------------------------------------------------------------+
> +    |63 Next parameter offset 32|31 Param Version 16|15 Param ID           0|
> +    +-----------------------------------------------------------------------+
> +    |63                 Parameter Data                                     0|
> +    +-----------------------------------------------------------------------+
> +
> +Offset 0x00
> +Type - The type of DFH (e.g. FME, AFU, or private feature).
> +DFH VER - The version of the DFH.
> +Rsvd - Currently unused.
> +EOL - Set if this DFH is the end of the Device Feature List (DFL).
> +Next - The offset of the next DFH in the DFL from the start of the DFH.
> +If EOL is set, Next refers to size of mmio for last feature in the list.
> +ID - If Type field is 'private feature', then ID of the private feature.
> +
> +Offset 0x08
> +GUID_L - Least significant 64 bits of a 128 bit Globally Unique Identifier.
> +
> +Offset 0x10
> +GUID_H - Most significant 64 bits of a 128 bit Globally Unique Identifier
> +if Type is FME or AFU.

A copy-paste error?

> +
> +Offset 0x18
> +Address/Offset - If Rel bit is set, then high 63 bits of a 16 bit aligned
> +absolute address for the location of the feature's registers.
> +If Rel bit is clear, then the feature's registers start at the
> +offset from the start of the DFH.
> +
> +Offset 0x20
> +Reg Size - Size of feature's register set.
> +Params - Set if DFH has one or more parameter blocks.
> +Group - Id of group if feature is part of a group.
> +Instance - Id of instance of feature within a group.
> +
> +Offset 0x28 if feature has parameters
> +Next - High 30 bits of a 32 bit aligned offset to the next parameter block.
> +If EOP set, size of last parameter.
> +Param Version - Version of Param ID.
> +Param ID - ID of parameter.
> +
> +Offset 0x30
> +Parameter Data - Parameter data whose size and format is defined by version
> +and ID of the parameter.

I'd reverse the order and say "ID and version" (kind of major thing 
first).

> +
>  Open discussion
>  ===============
>  FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration
> 

-- 
 i.


  parent reply	other threads:[~2022-10-21  8:32 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20 21:26 [PATCH v4 0/4] Enhance definition of DFH and use enhancements for uart driver matthew.gerlach
2022-10-20 21:26 ` [PATCH v4 1/4] Documentation: fpga: dfl: Add documentation for DFHv1 matthew.gerlach
2022-10-21  3:55   ` Bagas Sanjaya
2022-10-24 15:01     ` matthew.gerlach
2022-10-21  8:28   ` Ilpo Järvinen [this message]
2022-10-21  8:36     ` Ilpo Järvinen
2022-10-20 21:26 ` [PATCH v4 2/4] fpga: dfl: Add DFHv1 Register Definitions matthew.gerlach
2022-10-21  8:06   ` Ilpo Järvinen
2022-10-24 15:03     ` matthew.gerlach
2022-10-20 21:26 ` [PATCH v4 3/4] fpga: dfl: add basic support DFHv1 matthew.gerlach
2022-10-20 22:07   ` Andy Shevchenko
2022-10-24 14:56     ` matthew.gerlach
2022-10-21  8:58   ` Ilpo Järvinen
2022-10-24 15:09     ` matthew.gerlach
2022-10-21  9:07   ` Ilpo Järvinen
2022-10-29 13:08   ` Xu Yilun
2022-10-29 14:47     ` matthew.gerlach
2022-11-01 22:37       ` matthew.gerlach
2022-11-03  1:36         ` Xu Yilun
2022-10-30 22:06     ` Andy Shevchenko
2022-10-31  1:16       ` Xu Yilun
2022-10-31 15:34         ` Andy Shevchenko
2022-10-31 20:15           ` matthew.gerlach
2022-11-01  1:55           ` Xu Yilun
2022-10-20 21:26 ` [PATCH v4 4/4] tty: serial: 8250: add DFL bus driver for Altera 16550 matthew.gerlach
2022-10-20 22:13   ` Andy Shevchenko
2022-10-21  4:33   ` Greg KH
2022-10-21  9:24   ` Ilpo Järvinen
2022-10-29 15:24   ` Xu Yilun
2022-11-01  0:34     ` matthew.gerlach
2022-11-01  1:46       ` Xu Yilun
2022-11-01 16:04         ` matthew.gerlach
2022-11-01 16:30           ` Ilpo Järvinen
2022-11-01 17:39             ` matthew.gerlach
2022-11-02  9:57               ` Ilpo Järvinen
2022-11-08 12:48                 ` Marco Pagani
2022-11-08 12:51                   ` Ilpo Järvinen

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=d265dae0-fe4b-8ac0-fb9e-2a7345b279a2@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=basheer.ahmed.muddebihal@intel.com \
    --cc=corbet@lwn.net \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=hao.wu@intel.com \
    --cc=jirislaby@kernel.org \
    --cc=johan@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=macro@orcam.me.uk \
    --cc=marpagan@redhat.com \
    --cc=matthew.gerlach@linux.intel.com \
    --cc=mdf@kernel.org \
    --cc=niklas.soderlund+renesas@ragnatech.se \
    --cc=russell.h.weight@intel.com \
    --cc=tianfei.zhang@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.