linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Tull <atull@kernel.org>
To: Wu Hao <hao.wu@intel.com>
Cc: Moritz Fischer <mdf@kernel.org>,
	linux-fpga@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-api@vger.kernel.org, "Kang, Luwei" <luwei.kang@intel.com>,
	"Zhang, Yi Z" <yi.z.zhang@intel.com>,
	Tim Whisonant <tim.whisonant@intel.com>,
	Enno Luebbers <enno.luebbers@intel.com>,
	Shiva Rao <shiva.rao@intel.com>,
	Christopher Rauer <christopher.rauer@intel.com>
Subject: Re: [PATCH v3 04/21] fpga: add device feature list support
Date: Wed, 20 Dec 2017 16:29:52 -0600	[thread overview]
Message-ID: <CANk1AXQ_9+m-MvawwhaSpSfxO-Psg1F37vA9MfMcL4Q2t65dVA@mail.gmail.com> (raw)
In-Reply-To: <1511764948-20972-5-git-send-email-hao.wu@intel.com>

On Mon, Nov 27, 2017 at 12:42 AM, Wu Hao <hao.wu@intel.com> wrote:

Hi Hao,

> +
> +enum port_feature_id {
> +       PORT_FEATURE_ID_HEADER = 0x0,
> +       PORT_FEATURE_ID_ERROR = 0x1,
> +       PORT_FEATURE_ID_UMSG = 0x2,
> +       PORT_FEATURE_ID_PR = 0x3,
> +       PORT_FEATURE_ID_STP = 0x4,
> +       PORT_FEATURE_ID_UAFU = 0x5,
> +       PORT_FEATURE_ID_MAX = 0x6,
> +};
> +
> +#define FME_FEATURE_NUM                        FME_FEATURE_ID_MAX
> +#define PORT_FEATURE_NUM               PORT_FEATURE_ID_MAX
> +
> +#define FPGA_FEATURE_DEV_FME           "fpga-dfl-fme"
> +#define FPGA_FEATURE_DEV_PORT          "fpga-dfl-port"
> +
> +static inline int feature_platform_data_size(const int num)
> +{
> +       return sizeof(struct feature_platform_data) +
> +               num * sizeof(struct feature);
> +}
> +
> +int fpga_port_id(struct platform_device *pdev);
> +
> +static inline int fpga_port_check_id(struct platform_device *pdev,
> +                                    void *pport_id)
> +{
> +       return fpga_port_id(pdev) == *(int *)pport_id;
> +}
> +
> +void __fpga_port_enable(struct platform_device *pdev);
> +int __fpga_port_disable(struct platform_device *pdev);
> +
> +static inline void fpga_port_enable(struct platform_device *pdev)
> +{
> +       struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> +
> +       mutex_lock(&pdata->lock);
> +       __fpga_port_enable(pdev);
> +       mutex_unlock(&pdata->lock);
> +}
> +
> +static inline int fpga_port_disable(struct platform_device *pdev)
> +{
> +       struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> +       int ret;
> +
> +       mutex_lock(&pdata->lock);
> +       ret = __fpga_port_disable(pdev);
> +       mutex_unlock(&pdata->lock);
> +
> +       return ret;
> +}
> +
> +static inline int __fpga_port_reset(struct platform_device *pdev)
> +{
> +       int ret;
> +
> +       ret = __fpga_port_disable(pdev);
> +       if (ret)
> +               return ret;
> +
> +       __fpga_port_enable(pdev);
> +
> +       return 0;
> +}
> +
> +static inline int fpga_port_reset(struct platform_device *pdev)
> +{
> +       struct feature_platform_data *pdata = dev_get_platdata(&pdev->dev);
> +       int ret;
> +
> +       mutex_lock(&pdata->lock);
> +       ret = __fpga_port_reset(pdev);
> +       mutex_unlock(&pdata->lock);
> +
> +       return ret;
> +}

I see that the port code is included as part of the enumeration code.
This is not very future-proofed, if a different port needs to be
supported.

The port is a FPGA fabric based bridge with expanded functionality,
right?  So it is similar to the altera freeze bridge, but adds the
ability to reset the fabric and some other features are promised in
the future, IIUC.  I still think that the port could be implemented in
the bridge driver .c file instead of being here as part of the
enumeration code.   For that to happen, some APIs would need to be
added to the bridge framework and the FPGA region framework.  Then the
reset can be requested through a new FPGA region API function.

The advantage of this is that if this patchset evolves and there is
some other v2 port driver needed, it can be a different driver if it
needs to be.

If the port reset is really a fabric reset, (correct me if I'm
remembering wrongly) then it would be helpful to call it a
fabric_reset.  This would be the first bridge driver supporting fabric
reset.  I think it won't be the last.

So what I'm proposing would be added/changed would be:
* move all the bridge code to fpga-dfl-fme-br.c
* add .fabric_reset to bridge ops
* add fpga_bridges_reset to fpga-bridge.c (a new function that goes
through a list of bridges and calls the reset ops if it exists,
ignores the bridges where it doesn't exist)
* add fpga_region_fabric_reset to fpga-region.c.  This function gets
the region, gets the bridges, calls fpga_bridges_reset (can steal code
from fpga_region_program_fpga)
* the rest of the patchset can use fpga_region_fabric_reset instead of
fpga_port_reset

Alan

  parent reply	other threads:[~2017-12-20 22:30 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27  6:42 [PATCH v3 00/21] Intel FPGA Device Drivers Wu Hao
2017-11-27  6:42 ` [PATCH v3 01/21] docs: fpga: add a document for Intel FPGA driver overview Wu Hao
2017-12-04 19:55   ` Alan Tull
2017-12-05  3:57     ` Wu Hao
2017-12-06 10:04     ` David Laight
2017-12-20 22:31   ` Alan Tull
2017-12-21  6:02     ` Wu Hao
2017-11-27  6:42 ` [PATCH v3 02/21] fpga: mgr: add region_id to fpga_image_info Wu Hao
2017-11-29  6:11   ` Moritz Fischer
2017-12-04 20:26     ` Alan Tull
2017-12-05  3:36       ` Wu Hao
2018-01-31 15:35         ` Alan Tull
2018-02-01  5:05           ` Wu Hao
2017-11-27  6:42 ` [PATCH v3 03/21] fpga: mgr: add status for fpga-manager Wu Hao
2017-12-04 20:55   ` Alan Tull
2017-12-05  4:08     ` Wu Hao
2017-12-12 18:18   ` Alan Tull
2017-12-13  4:48     ` Wu Hao
2017-11-27  6:42 ` [PATCH v3 04/21] fpga: add device feature list support Wu Hao
2017-11-29  6:07   ` Moritz Fischer
2017-11-30  5:59     ` Wu Hao
2017-12-20 22:29   ` Alan Tull [this message]
2017-12-21  0:58     ` Alan Tull
2017-12-21  7:22       ` Wu Hao
2017-12-22  8:45         ` Wu Hao
2018-01-31 23:22           ` Alan Tull
2017-11-27  6:42 ` [PATCH v3 05/21] fpga: dfl: add chardev support for feature devices Wu Hao
2017-11-27  6:42 ` [PATCH v3 06/21] fpga: dfl: adds fpga_cdev_find_port Wu Hao
2018-02-05 22:08   ` Alan Tull
2018-02-06  2:37     ` Wu Hao
2017-11-27  6:42 ` [PATCH v3 07/21] fpga: dfl: add feature device infrastructure Wu Hao
2017-11-27  6:42 ` [PATCH v3 08/21] fpga: add Intel FPGA DFL PCIe device Wu Hao
2017-11-27 10:28   ` David Laight
2017-11-28  3:15     ` Wu Hao
2017-12-04 19:46       ` Alan Tull
2017-12-05  3:33         ` Wu Hao
2017-12-05 17:00           ` Alan Tull
2017-12-06  5:30             ` Wu Hao
2017-12-06  9:44               ` David Laight
2017-12-06 15:29                 ` Alan Tull
2017-12-06 16:28                   ` David Laight
2017-12-06 22:39                     ` Alan Tull
2018-02-01 21:59               ` Alan Tull
2018-02-13  9:36                 ` Wu Hao
2017-12-06  9:34           ` David Laight
2017-12-07  3:47             ` Wu Hao
2017-12-06  9:31         ` David Laight
2017-11-27  6:42 ` [PATCH v3 09/21] fpga: intel-dfl-pci: add enumeration for feature devices Wu Hao
2017-12-07 21:41   ` Alan Tull
2017-12-08  9:25     ` Wu Hao
2017-11-27  6:42 ` [PATCH v3 10/21] fpga: dfl: add FPGA Management Engine driver basic framework Wu Hao
2017-11-27  6:42 ` [PATCH v3 11/21] fpga: dfl: fme: add header sub feature support Wu Hao
2018-02-12 16:51   ` Alan Tull
2018-02-13  3:44     ` Wu Hao
2017-11-27  6:42 ` [PATCH v3 12/21] fpga: dfl: fme: add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support Wu Hao
2018-01-31 15:31   ` Alan Tull
2018-02-01  5:11     ` Wu Hao
2018-02-01 15:11       ` Moritz Fischer
2017-11-27  6:42 ` [PATCH v3 13/21] fpga: dfl: fme: add partial reconfiguration sub feature support Wu Hao
2017-11-27  6:42 ` [PATCH v3 14/21] fpga: dfl: add fpga manager platform driver for FME Wu Hao
2018-02-01 22:00   ` Alan Tull
2018-02-02  9:42     ` Wu Hao
2018-02-03  0:26       ` Luebbers, Enno
2018-02-03 10:41         ` Moritz Fischer
2018-02-04 10:05           ` Wu Hao
2018-02-05 17:21             ` Alan Tull
2018-02-06  2:17               ` Wu Hao
2018-02-06  4:25                 ` Alan Tull
2018-02-06  5:23                   ` Wu Hao
2018-02-06  6:44                   ` Moritz Fischer
2018-02-04  9:37         ` Wu Hao
2018-02-05 18:36           ` Luebbers, Enno
2018-02-06  1:47             ` Wu Hao
2018-02-06  4:25               ` Alan Tull
2018-02-06  6:47                 ` Wu Hao
2018-02-06 18:53                   ` Alan Tull
2018-02-07  4:52                     ` Wu Hao
2018-02-07 22:37                       ` Alan Tull
2017-11-27  6:42 ` [PATCH v3 15/21] fpga: dfl: add fpga bridge " Wu Hao
2018-01-31 15:16   ` Alan Tull
2018-02-01  5:15     ` Wu Hao
2018-02-01 15:11       ` Moritz Fischer
2017-11-27  6:42 ` [PATCH v3 16/21] fpga: dfl: add fpga region " Wu Hao
2018-01-31 20:46   ` Alan Tull
2018-02-01  5:23     ` Wu Hao
2018-02-01 15:13       ` Moritz Fischer
2017-11-27  6:42 ` [PATCH v3 17/21] fpga: dfl: add FPGA Accelerated Function Unit driver basic framework Wu Hao
2017-11-27  6:42 ` [PATCH v3 18/21] fpga: dfl: afu: add header sub feature support Wu Hao
2018-02-12 17:43   ` Alan Tull
2018-02-13  3:33     ` Wu Hao
2017-11-27  6:42 ` [PATCH v3 19/21] fpga: dfl: afu: add FPGA_GET_API_VERSION/CHECK_EXTENSION ioctls support Wu Hao
2018-01-31 14:52   ` Alan Tull
2018-02-01  5:16     ` Wu Hao
2018-02-01 15:13       ` Moritz Fischer
2018-02-02  9:08         ` Wu Hao
2017-11-27  6:42 ` [PATCH v3 20/21] fpga: dfl: afu: add user afu sub feature support Wu Hao
2017-11-27  6:42 ` [PATCH v3 21/21] fpga: dfl: afu: add FPGA_PORT_DMA_MAP/UNMAP ioctls support Wu Hao
2017-11-27 21:26 ` [PATCH v3 00/21] Intel FPGA Device Drivers Alan Tull

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=CANk1AXQ_9+m-MvawwhaSpSfxO-Psg1F37vA9MfMcL4Q2t65dVA@mail.gmail.com \
    --to=atull@kernel.org \
    --cc=christopher.rauer@intel.com \
    --cc=enno.luebbers@intel.com \
    --cc=hao.wu@intel.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luwei.kang@intel.com \
    --cc=mdf@kernel.org \
    --cc=shiva.rao@intel.com \
    --cc=tim.whisonant@intel.com \
    --cc=yi.z.zhang@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).