[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YBHexYg/Bw1U7LQm@epycbox.lan>
Date: Wed, 27 Jan 2021 13:44:37 -0800
From: Moritz Fischer <mdf@...nel.org>
To: Michal Simek <michal.simek@...inx.com>
Cc: Nava kishore Manne <navam@...inx.com>,
Moritz Fischer <mdf@...nel.org>,
"trix@...hat.com" <trix@...hat.com>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"linux-fpga@...r.kernel.org" <linux-fpga@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
git <git@...inx.com>,
"chinnikishore369@...il.com" <chinnikishore369@...il.com>,
Appana Durga Kedareswara Rao <appanad@...inx.com>
Subject: Re: [PATCH 3/3] fpga: versal-fpga: Add versal fpga manager driver
On Wed, Jan 27, 2021 at 10:16:32AM +0100, Michal Simek wrote:
> Hi
>
> On 1/27/21 9:57 AM, Nava kishore Manne wrote:
> > Hi Moritz,
> >
> > Please find my response inline.
> >
> >> -----Original Message-----
> >> From: Moritz Fischer <mdf@...nel.org>
> >> Sent: Sunday, January 24, 2021 5:04 AM
> >> To: Nava kishore Manne <navam@...inx.com>
> >> Cc: Moritz Fischer <mdf@...nel.org>; trix@...hat.com;
> >> robh+dt@...nel.org; Michal Simek <michals@...inx.com>; linux-
> >> fpga@...r.kernel.org; devicetree@...r.kernel.org; linux-arm-
> >> kernel@...ts.infradead.org; linux-kernel@...r.kernel.org; git
> >> <git@...inx.com>; chinnikishore369@...il.com; Appana Durga Kedareswara
> >> Rao <appanad@...inx.com>
> >> Subject: Re: [PATCH 3/3] fpga: versal-fpga: Add versal fpga manager driver
> >>
> >> Hi Nava,
> >>
> >> On Fri, Jan 22, 2021 at 10:34:15AM +0000, Nava kishore Manne wrote:
> >>> Hi Moritz,
> >>>
> >>> Thanks for the review.
> >>> Please find my response inline.
> >>>
> >>>> -----Original Message-----
> >>>> From: Moritz Fischer <mdf@...nel.org>
> >>>> Sent: Tuesday, January 19, 2021 6:03 AM
> >>>> To: Nava kishore Manne <navam@...inx.com>
> >>>> Cc: mdf@...nel.org; trix@...hat.com; robh+dt@...nel.org; Michal
> >>>> Simek <michals@...inx.com>; linux-fpga@...r.kernel.org;
> >>>> devicetree@...r.kernel.org; linux-arm-kernel@...ts.infradead.org;
> >>>> linux- kernel@...r.kernel.org; git <git@...inx.com>;
> >>>> chinnikishore369@...il.com; Appana Durga Kedareswara Rao
> >>>> <appanad@...inx.com>
> >>>> Subject: Re: [PATCH 3/3] fpga: versal-fpga: Add versal fpga manager
> >>>> driver
> >>>>
> >>>> Hi Nava,
> >>>>
> >>>> On Mon, Jan 18, 2021 at 08:13:18AM +0530, Nava kishore Manne wrote:
> >>>>> This patch adds driver for versal fpga manager.
> >>>> Nit: Add support for Xilinx Versal FPGA manager
> >>>
> >>> Will fix in v2.
> >>>
> >>>>>
> >>>>> PDI source type can be DDR, OCM, QSPI flash etc..
> >>>> No idea what PDI is :)
> >>>
> >>> Programmable device image (PDI).
> >>> This file is generated by Xilinx Vivado tool and it contains configuration data
> >> objects.
> >>>
> >>>>> But driver allocates memory always from DDR, Since driver supports
> >>>>> only DDR source type.
> >>>>>
> >>>>> Signed-off-by: Appana Durga Kedareswara rao
> >>>>> <appana.durga.rao@...inx.com>
> >>>>> Signed-off-by: Nava kishore Manne <nava.manne@...inx.com>
> >>>>> ---
> >>>>> drivers/fpga/Kconfig | 8 ++
> >>>>> drivers/fpga/Makefile | 1 +
> >>>>> drivers/fpga/versal-fpga.c | 149
> >>>>> +++++++++++++++++++++++++++++++++++++
> >>>>> 3 files changed, 158 insertions(+) create mode 100644
> >>>>> drivers/fpga/versal-fpga.c
> >>>>>
> >>>>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index
> >>>>> 5645226ca3ce..9f779c3a6739 100644
> >>>>> --- a/drivers/fpga/Kconfig
> >>>>> +++ b/drivers/fpga/Kconfig
> >>>>> @@ -216,4 +216,12 @@ config FPGA_MGR_ZYNQMP_FPGA
> >>>>> to configure the programmable logic(PL) through PS
> >>>>> on ZynqMP SoC.
> >>>>>
> >>>>> +config FPGA_MGR_VERSAL_FPGA
> >>>>> + tristate "Xilinx Versal FPGA"
> >>>>> + depends on ARCH_ZYNQMP || COMPILE_TEST
> >>>>> + help
> >>>>> + Select this option to enable FPGA manager driver support for
> >>>>> + Xilinx Versal SOC. This driver uses the versal soc firmware
> >>>>> + interface to load programmable logic(PL) images
> >>>>> + on versal soc.
> >>>>> endif # FPGA
> >>>>> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile index
> >>>>> d8e21dfc6778..40c9adb6a644 100644
> >>>>> --- a/drivers/fpga/Makefile
> >>>>> +++ b/drivers/fpga/Makefile
> >>>>> @@ -18,6 +18,7 @@ obj-$(CONFIG_FPGA_MGR_TS73XX) +=
> >>>> ts73xx-fpga.o
> >>>>> obj-$(CONFIG_FPGA_MGR_XILINX_SPI) += xilinx-spi.o
> >>>>> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> >>>>> obj-$(CONFIG_FPGA_MGR_ZYNQMP_FPGA) += zynqmp-fpga.o
> >>>>> +obj-$(CONFIG_FPGA_MGR_VERSAL_FPGA) += versal-fpga.o
> >>>>> obj-$(CONFIG_ALTERA_PR_IP_CORE) += altera-pr-ip-core.o
> >>>>> obj-$(CONFIG_ALTERA_PR_IP_CORE_PLAT) += altera-pr-ip-core-plat.o
> >>>>>
> >>>>> diff --git a/drivers/fpga/versal-fpga.c
> >>>>> b/drivers/fpga/versal-fpga.c new file mode 100644 index
> >>>>> 000000000000..2a42aa78b182
> >>>>> --- /dev/null
> >>>>> +++ b/drivers/fpga/versal-fpga.c
> >>>>> @@ -0,0 +1,149 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0+
> >>>>> +/*
> >>>>> + * Copyright (C) 2021 Xilinx, Inc.
> >>>>> + */
> >>>>> +
> >>>>> +#include <linux/dma-mapping.h>
> >>>>> +#include <linux/fpga/fpga-mgr.h>
> >>>>> +#include <linux/io.h>
> >>>>> +#include <linux/kernel.h>
> >>>>> +#include <linux/module.h>
> >>>>> +#include <linux/of_address.h>
> >>>>> +#include <linux/string.h>
> >>>>> +#include <linux/firmware/xlnx-zynqmp.h>
> >>>>> +
> >>>>> +/* Constant Definitions */
> >>>>> +#define PDI_SOURCE_TYPE 0xF
> >>>>> +
> >>>>> +/**
> >>>>> + * struct versal_fpga_priv - Private data structure
> >>>>> + * @dev: Device data structure
> >>>>> + * @flags: flags which is used to identify the PL Image type
> >>>>> + */
> >>>>> +struct versal_fpga_priv {
> >>>>> + struct device *dev;
> >>>>> + u32 flags;
> >>>> This seems unused ... please introduce them when/if you start using
> >> them.
> >>>
> >>> Will fix in v2.
> >>>
> >>>>> +};
> >>>>> +
> >>>>> +static int versal_fpga_ops_write_init(struct fpga_manager *mgr,
> >>>>> + struct fpga_image_info *info,
> >>>>> + const char *buf, size_t size) {
> >>>>> + struct versal_fpga_priv *priv;
> >>>>> +
> >>>>> + priv = mgr->priv;
> >>>>> + priv->flags = info->flags;
> >>>> ? What uses this ? It seems this function could just be 'return 0' right now.
> >>>
> >>> Will fix in v2.
> >>>
> >>>>> +
> >>>>> + return 0;
> >>>>> +}
> >>>>> +
> >>>>> +static int versal_fpga_ops_write(struct fpga_manager *mgr,
> >>>>> + const char *buf, size_t size) {
> >>>>> + struct versal_fpga_priv *priv;
> >>>>> + dma_addr_t dma_addr = 0;
> >>>>> + char *kbuf;
> >>>>> + int ret;
> >>>>> +
> >>>>> + priv = mgr->priv;
> >>>>> +
> >>>>> + kbuf = dma_alloc_coherent(priv->dev, size, &dma_addr,
> >>>> GFP_KERNEL);
> >>>>> + if (!kbuf)
> >>>>> + return -ENOMEM;
> >>>>> +
> >>>>> + memcpy(kbuf, buf, size);
> >>>>> +
> >>>>> + wmb(); /* ensure all writes are done before initiate FW call */
> >>>>> +
> >>>>> + ret = zynqmp_pm_load_pdi(PDI_SOURCE_TYPE, dma_addr);
> >>>>> +
> >>>>> + dma_free_coherent(priv->dev, size, kbuf, dma_addr);
> >>>>> +
> >>>>> + return ret;
> >>>>> +}
> >>>>> +
> >>>>> +static int versal_fpga_ops_write_complete(struct fpga_manager *mgr,
> >>>>> + struct fpga_image_info *info) {
> >>>>> + return 0;
> >>>>> +}
> >>>>> +
> >>>>> +static enum fpga_mgr_states versal_fpga_ops_state(struct
> >>>>> +fpga_manager
> >>>>> +*mgr) {
> >>>>> + return FPGA_MGR_STATE_OPERATING;
> >>>> Is that always the case? Shouldn't that be
> >> FPGA_MGR_STATE_UNKNOWN?
> >>>
> >>> For Versal SoC base PDI is always configured prior to Linux boot up. So I
> >> make the fpga state as OPERATING.
> >>> Please let know if it is not a proper implementation will think about the
> >> alternate solution.
> >>
> >> So you're saying I can't boot a Versal SoC without a PDI / Bitstream loaded?
> >> Interesting :)
> >>>
> >
> > For Versal SoC Vivado generated base PDI is always needed to bring-up the board.
>
> Look at PDI as ps7_init/psu_init file but in different format. And
> bitstream is optional part of it (like a one partition).
So at that point I could still have no bitstream loaded (optional), and
my status would be 'unknown' not 'operating' if I cannot tell the two
cases apart. What am I missing? :)
Thanks,
Moritz
Powered by blists - more mailing lists