| Message ID | 20220906190426.3139760-1-matthew.gerlach@linux.intel.com |
|---|---|
| Headers | show |
| Series | Enhance definition of DFH and use enhancements for uart driver | expand |
On Tue, 6 Sep 2022, Andy Shevchenko wrote: > On Tue, Sep 06, 2022 at 12:04:22PM -0700, matthew.gerlach@linux.intel.com wrote: >> From: Matthew Gerlach <matthew.gerlach@linux.intel.com> >> >> Add documentation describing the extentions provided by Version >> 1 of the Device Feature Header (DFHv1). > > ... > >> +With DFHv0, not all features types contained a GUID. DFHv1 makes the GUILD standard >> +across all types. > > GUI_L_D? > Thanks for the review and pointing out the typo. Matthew Gerlach > -- > With Best Regards, > Andy Shevchenko > > >
On Tue, 6 Sep 2022, Andy Shevchenko wrote: > On Tue, Sep 06, 2022 at 12:04:26PM -0700, matthew.gerlach@linux.intel.com wrote: >> From: Matthew Gerlach <matthew.gerlach@linux.intel.com> >> >> Add a Device Feature List (DFL) bus driver for the Altera >> 16550 implementation of UART. > > ... > >> +#include <linux/dfl.h> > >> +#include <linux/version.h> > > Hmm... Do we need this? We do not need this. > >> +#include <linux/serial.h> >> +#include <linux/serial_8250.h> >> +#include <linux/kernel.h> >> +#include <linux/module.h> >> +#include <linux/bitfield.h> >> +#include <linux/io-64-nonatomic-lo-hi.h> > > Can this block be sorted alphabetically? Yes, they can and should be sorted alphabetically. > > ... > >> +int feature_uart_walk(struct dfl_uart *dfluart, resource_size_t max) >> +{ >> + void __iomem *param_base; >> + int off; >> + u64 v; >> + >> + v = readq(dfluart->csr_base + DFHv1_CSR_ADDR); >> + dfluart->csr_addr = FIELD_GET(DFHv1_CSR_ADDR_MASK, v); >> + >> + v = readq(dfluart->csr_base + DFHv1_CSR_SIZE_GRP); >> + dfluart->csr_size = FIELD_GET(DFHv1_CSR_SIZE_GRP_SIZE, v); >> + >> + if (dfluart->csr_addr == 0 || dfluart->csr_size == 0) { >> + dev_err(dfluart->dev, "FIXME bad dfh address and size\n"); > > DFH ? Yes,"DFH" is better than "dfh" in the message. > >> + return -EINVAL; >> + } >> + >> + if (!FIELD_GET(DFHv1_CSR_SIZE_GRP_HAS_PARAMS, v)) { >> + dev_err(dfluart->dev, "missing required parameters\n"); > > Not sure I understood what parameters are here. FPGA VHDL? Configuration? RTL? How about "missing required DFH parameters\n"? > >> + return -EINVAL; >> + } >> + >> + param_base = dfluart->csr_base + DFHv1_PARAM_HDR; >> + >> + off = dfl_find_param(param_base, max, DFHv1_PARAM_ID_CLK_FRQ); >> + if (off < 0) { >> + dev_err(dfluart->dev, "missing CLK_FRQ param\n"); >> + return -EINVAL; >> + } >> + >> + dfluart->uart_clk = readq(param_base + off + DFHv1_PARAM_DATA); > >> + dev_dbg(dfluart->dev, "UART_CLK_ID %llu Hz\n", dfluart->uart_clk); > > Isn't this available via normal interfaces to user? I am not sure what "normal interfaces to user" you are referring to. The code is just trying to read the frequency of the input clock to the uart from a DFH paramter. > >> + off = dfl_find_param(param_base, max, DFHv1_PARAM_ID_FIFO_LEN); >> + if (off < 0) { >> + dev_err(dfluart->dev, "missing FIFO_LEN param\n"); >> + return -EINVAL; >> + } >> + >> + dfluart->fifo_len = readq(param_base + off + DFHv1_PARAM_DATA); >> + dev_dbg(dfluart->dev, "UART_FIFO_ID fifo_len %llu\n", dfluart->fifo_len); >> + >> + off = dfl_find_param(param_base, max, DFHv1_PARAM_ID_REG_LAYOUT); >> + if (off < 0) { >> + dev_err(dfluart->dev, "missing REG_LAYOUT param\n"); >> + return -EINVAL; >> + } >> + >> + v = readq(param_base + off + DFHv1_PARAM_DATA); >> + dfluart->fifo_size = FIELD_GET(DFHv1_PARAM_ID_REG_WIDTH, v); >> + dfluart->reg_shift = FIELD_GET(DFHv1_PARAM_ID_REG_SHIFT, v); >> + dev_dbg(dfluart->dev, "UART_LAYOUT_ID width %d shift %d\n", >> + dfluart->fifo_size, dfluart->reg_shift); >> + >> + return 0; >> +} >> + >> +static int dfl_uart_probe(struct dfl_device *dfl_dev) >> +{ >> + struct device *dev = &dfl_dev->dev; >> + struct uart_8250_port uart; >> + struct dfl_uart *dfluart; >> + int ret; >> + >> + memset(&uart, 0, sizeof(uart)); >> + >> + dfluart = devm_kzalloc(dev, sizeof(*dfluart), GFP_KERNEL); >> + if (!dfluart) >> + return -ENOMEM; >> + >> + dfluart->csr_base = devm_ioremap_resource(dev, &dfl_dev->mmio_res); >> + if (IS_ERR(dfluart->csr_base)) { > >> + dev_err(dev, "failed to get mem resource!\n"); > > The above call have a few different messages depending on error code. > No need to repeat this. I will remove the call to dev_err(). > >> + return PTR_ERR(dfluart->csr_base); >> + } >> + >> + dfluart->dev = dev; >> + >> + ret = feature_uart_walk(dfluart, resource_size(&dfl_dev->mmio_res)); >> + if (ret < 0) { >> + dev_err(dev, "failed to uart feature walk %d\n", ret); > >> + return -EINVAL; > > Why shadowing error code? > What about > > return dev_err_probe(dev, ret, ...); > ? > Using dev_err_probe seems like the way to go. >> + } >> + >> + dev_dbg(dev, "nr_irqs %d %p\n", dfl_dev->num_irqs, dfl_dev->irqs); >> + >> + if (dfl_dev->num_irqs == 1) >> + uart.port.irq = dfl_dev->irqs[0]; >> + >> + switch (dfluart->fifo_len) { >> + case 32: >> + uart.port.type = PORT_ALTR_16550_F32; >> + break; >> + >> + case 64: >> + uart.port.type = PORT_ALTR_16550_F64; >> + break; >> + >> + case 128: >> + uart.port.type = PORT_ALTR_16550_F128; >> + break; >> + >> + default: >> + dev_err(dev, "bad fifo_len %llu\n", dfluart->fifo_len); >> + return -EINVAL; >> + } >> + >> + uart.port.iotype = UPIO_MEM32; >> + uart.port.membase = dfluart->csr_base + dfluart->csr_addr; >> + uart.port.mapsize = dfluart->csr_size; >> + uart.port.regshift = dfluart->reg_shift; >> + uart.port.uartclk = dfluart->uart_clk; >> + >> + /* register the port */ >> + ret = serial8250_register_8250_port(&uart); >> + if (ret < 0) { >> + dev_err(dev, "unable to register 8250 port %d.\n", ret); >> + return -EINVAL; >> + } >> + dev_info(dev, "serial8250_register_8250_port %d\n", ret); >> + dfluart->line = ret; >> + dev_set_drvdata(dev, dfluart); >> + >> + return 0; >> +} >> + >> +static void dfl_uart_remove(struct dfl_device *dfl_dev) >> +{ >> + struct dfl_uart *dfluart = dev_get_drvdata(&dfl_dev->dev); >> + >> + if (dfluart->line > 0) >> + serial8250_unregister_port(dfluart->line); >> +} > > ... > >> +#define FME_FEATURE_ID_UART 0x24 > > Purpose of this definition? For me with or without is still an ID. I don't think I understand the question. Is the name of the macro unclear, or do you think it is not necessary? > >> +static const struct dfl_device_id dfl_uart_ids[] = { >> + { FME_ID, FME_FEATURE_ID_UART }, >> + { } >> +}; > > ... > >> +static struct dfl_driver dfl_uart_driver = { >> + .drv = { >> + .name = "dfl-uart", >> + }, >> + .id_table = dfl_uart_ids, >> + .probe = dfl_uart_probe, >> + .remove = dfl_uart_remove, >> +}; > >> + > > No need to have this blank line. I will remove the blank line. > >> +module_dfl_driver(dfl_uart_driver); > > ... > >> +MODULE_DEVICE_TABLE(dfl, dfl_uart_ids); > > Move this closer to the definition. That's how other drivers do in the kernel. Thanks for the suggestion. > > ... > >> --- a/drivers/tty/serial/8250/Kconfig >> +++ b/drivers/tty/serial/8250/Kconfig > >> --- a/drivers/tty/serial/8250/Makefile >> +++ b/drivers/tty/serial/8250/Makefile > > I know that the records in those files are not sorted, but can you try hard > to find the best place for them in those files from sorting point of view? > I will try to find a better place from sorting porint of view. > -- > With Best Regards, > Andy Shevchenko > > >
On 2022-09-06 at 12:04:24 -0700, matthew.gerlach@linux.intel.com wrote: > From: Basheer Ahmed Muddebihal <basheer.ahmed.muddebihal@linux.intel.com> > > This patch adds the definitions for DFHv1 header and related register > bitfields. > > Signed-off-by: Basheer Ahmed Muddebihal <basheer.ahmed.muddebihal@linux.intel.com> > Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> > --- > include/linux/dfl.h | 37 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/include/linux/dfl.h b/include/linux/dfl.h > index b5accdcfa368..61bcf20c1bc8 100644 > --- a/include/linux/dfl.h > +++ b/include/linux/dfl.h > @@ -23,6 +23,16 @@ > #define GUID_H 0x10 > #define NEXT_AFU 0x18 > > +/* > + * DFHv1 Register Offset definitons > + * In DHFv1, DFH + GUID + CSR_START + CSR_SIZE_GROUP + PARAM_HDR + PARAM_DATA > + * as common header registers > + */ > +#define DFHv1_CSR_ADDR 0x18 /* CSR Register start address */ > +#define DFHv1_CSR_SIZE_GRP 0x20 /* Size of Reg Block and Group/tag */ > +#define DFHv1_PARAM_HDR 0x28 /* Optional First Param header */ > +#define DFHv1_PARAM_DATA 0x8 /* Offset of Param data from Param header */ > + > #define DFH_SIZE 0x8 > > /* Device Feature Header Register Bitfield */ > @@ -30,8 +40,35 @@ > #define DFH_REVISION GENMASK_ULL(15, 12) /* Feature revision */ > #define DFH_NEXT_HDR_OFST GENMASK_ULL(39, 16) /* Offset to next DFH */ > #define DFH_EOL BIT_ULL(40) /* End of list */ > +#define DFH_VERSION GENMASK_ULL(59, 52) /* DFH version */ > #define DFH_TYPE GENMASK_ULL(63, 60) /* Feature type */ > > +/* > + * CSR Rel Bit, 1'b0 = relative (offset from feature DFH start), Reduce one whitespace indent. > + * 1'b1 = absolute (ARM or other non-PCIe use) > + */ > +#define DFHv1_CSR_ADDR_REL BIT_ULL(0) > + > +/* > + * CSR Header Register Bit Definitions > + */ Use oneline style comment should be OK? > +#define DFHv1_CSR_ADDR_MASK GENMASK_ULL(63, 1) /* 63:1 of CSR address */ > + > +/* > + * CSR SIZE Goup Register Bit Definitions > + */ Same concern > +#define DFHv1_CSR_SIZE_GRP_INSTANCE_ID GENMASK_ULL(15, 0) /* Enumeration instantiated IP */ > +#define DFHv1_CSR_SIZE_GRP_GROUPING_ID GENMASK_ULL(30, 16) /* Group Features/interfaces */ > +#define DFHv1_CSR_SIZE_GRP_HAS_PARAMS BIT_ULL(31) /* Presence of Parameters */ > +#define DFHv1_CSR_SIZE_GRP_SIZE GENMASK_ULL(63, 32) /* Size of CSR Block in bytes */ > + > +/* > + * PARAM Header Register Bit Definitions > + */ Same > +#define DFHv1_PARAM_HDR_ID GENMASK_ULL(15, 0) /* Id of this Param */ > +#define DFHv1_PARAM_HDR_VERSION GENMASK_ULL(31, 16) /* Version Param */ > +#define DFHv1_PARAM_HDR_NEXT_OFFSET GENMASK_ULL(63, 32) /* Offset of next Param */ > + > /** > * enum dfl_id_type - define the DFL FIU types > */ > -- > 2.25.1 >
On 2022-09-06 at 12:04:22 -0700, matthew.gerlach@linux.intel.com wrote: > From: Matthew Gerlach <matthew.gerlach@linux.intel.com> > > Add documentation describing the extentions provided by Version > 1 of the Device Feature Header (DFHv1). > > Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com> > --- > Documentation/fpga/dfl.rst | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst > index 15b670926084..31699b89781e 100644 > --- a/Documentation/fpga/dfl.rst > +++ b/Documentation/fpga/dfl.rst > @@ -561,6 +561,30 @@ new DFL feature via UIO direct access, its feature id should be added to the > driver's id_table. > > > +Extending the Device Feature Header - DFHv1 > +=========================================== > +The current 8 bytes of the Device Feature Header, hereafter referred to as > +to DFHv0, provide very little opportunity for the hardware to describe itself > +to software. Version 1 of the Device Feature Header (DFHv1) is being introduced > +to provide increased flexibility and extensibility to hardware designs using > +Device Feature Lists. The list below describes some of the goals behind the > +changes in DFHv1: > + > +* Provide a standardized mechanism for features to describe > + parameters/capabilities to software. > +* Standardize the use of a GUID for all DFHv1 types. > +* Decouple the location of the DFH from the register space of the feature itself. > + > +Modeled after PCI Capabilities, DFHv1 Parameters provide a mechanism to associate > +a list of parameter values to a particular feature. > + > +With DFHv0, not all features types contained a GUID. DFHv1 makes the GUILD standard > +across all types. > + > +With DFHv0, the register map of a given feature is located immediately following > +the DFHv0 in the memory space. With DFHv1, the location of the feature register > +map can be specified as an offset to the DFHv1 or as an absolute address. Could you make a table or diagram to describe the data structure layout of DFHv1 extention. Thanks, Yilun > + > Open discussion > =============== > FME driver exports one ioctl (DFL_FPGA_FME_PORT_PR) for partial reconfiguration > -- > 2.25.1 >
On Fri, 9 Sep 2022, Andy Shevchenko wrote: > On Thu, Sep 08, 2022 at 11:27:03AM -0700, matthew.gerlach@linux.intel.com wrote: >> On Tue, 6 Sep 2022, Andy Shevchenko wrote: >>> On Tue, Sep 06, 2022 at 12:04:26PM -0700, matthew.gerlach@linux.intel.com wrote: > > ... > >>>> + dev_dbg(dfluart->dev, "UART_CLK_ID %llu Hz\n", dfluart->uart_clk); >>> >>> Isn't this available via normal interfaces to user? >> >> I am not sure what "normal interfaces to user" you are referring to. The >> code is just trying to read the frequency of the input clock to the uart >> from a DFH paramter. > > I mean dev_dbg() call. The user can get uart_clk via one of the UART/serial > ABIs (don't remember which one, though). I don't think UART/serial ABIs to get the input clock frequency would be available until after the call to serial8250_register_8250_port() which needs the clock frequency as an input. > > > ... > >>>> +#define FME_FEATURE_ID_UART 0x24 >>> >>> Purpose of this definition? For me with or without is still an ID. >> >> I don't think I understand the question. Is the name of the macro unclear, >> or do you think it is not necessary? > > I mean how the definition is useful / useless. I.o.w. I think it's not > necessary. The macro may not be necessary, but its usage is consistent with other dfl bus drivers. Thanks for the feedback, Matthew Gerlach > > -- > With Best Regards, > Andy Shevchenko > > >
From: Matthew Gerlach <matthew.gerlach@intel.com> This patchset enhances the definition of the Device Feature Header (DFH) used by the Device Feature List (DFL) bus and then uses the new enhancements in a uart driver. Patch 1 updates the DFL documentation to provide the motivation behind the enhancements to the definition of the DFH. Patch 2 moves some of the DFH definitions to include/linux/dfl.h so that they can be accessed by drivers outside of drivers/fpga. Patch 3 adds the definitions for DFHv1. Patch 4 defines and uses a DFHv1 parameter to provide a generic mechanism for describing MSIX interrupts used by a particular feature instance. Patch 5 adds a DFL uart driver that makes use of the new features of DFHv1. Basheer Ahmed Muddebihal (2): fpga: dfl: Move the DFH definitions fpga: dfl: Add DFHv1 Register Definitions Matthew Gerlach (3): Documentation: fpga: dfl: Add documentation for DFHv1 fpga: dfl: add generic support for MSIX interrupts tty: serial: 8250: add DFL bus driver for Altera 16550. Documentation/fpga/dfl.rst | 24 ++++ drivers/fpga/dfl.c | 59 ++++++--- drivers/fpga/dfl.h | 22 +--- drivers/tty/serial/8250/8250_dfl.c | 188 +++++++++++++++++++++++++++++ drivers/tty/serial/8250/Kconfig | 9 ++ drivers/tty/serial/8250/Makefile | 1 + include/linux/dfl.h | 80 +++++++++++- 7 files changed, 347 insertions(+), 36 deletions(-) create mode 100644 drivers/tty/serial/8250/8250_dfl.c