Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1388984ybb; Thu, 9 Apr 2020 00:46:26 -0700 (PDT) X-Google-Smtp-Source: APiQypJJdcaQ1QkXIIc0Ll2/suZ9DqVG5i5tbvcTYOggUSJ+r0rt7v+195sZ1EYGrL6m4rQsaF5c X-Received: by 2002:a9d:4c0e:: with SMTP id l14mr8135508otf.226.1586418386519; Thu, 09 Apr 2020 00:46:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586418386; cv=none; d=google.com; s=arc-20160816; b=kDS4nsIV1m1zMYjcMPP/O8i/gdYkczFx7AIUcU1FkCQ2UFV9iO0BZzl+/OG2Z+fiMR l+dlsnSg8+ttRRnP9EST4zBIhGDIE752r6p0dTAV8AmcE0IyuNKDjNpvYbV/jlzwtfnf OYS0UiN/qZQiRbXf+NffBGy6hRBr7W7A7QrhcXH3kIJi2Hh5x3Wfaj/UEtmb7K9W39G0 vz4GoXoVOvgfgIEQyTsIVJuQ7rUUyqj+KgE4qKqWM1tqLiweb3L2J09EnkludoXeNNUv Eqxm+4nCmn10CMNKNQubcQnfgVu6CEp2KiNkffkiOD7Y3AXOTUU9aqUt4fXCOmcxxE+m sfCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=w5qFYQnHETipIvb5kB88U/UTP/2FdKjeYZh5xImmP0o=; b=f4bNKjzO2vGCvmSA8d/VMNH2j3ADw/T2d8IAQm8BoI4y8X00++7O9b69XIvOfn3VeC SdHwJDOicOcPkCsbXTs2FkZgxFXzrNC7j3Y42FfKQxsRN4rkB0tgUmtPXjQ9UaVqs2eW 2KOZDVCQhobZa+M2kglQeGry46zKCntExnuxc+WVj+Ta4/kT0CpzRRlCy/vpbuToqVNp 5s5b1m0G/xyzCI5noQ4URR6TUaPo3c7yH22peNV375t+n/raBhVUTW9XdKXm4qX+kGCX JgqNIPgOQei+MwDNvMqLeWeH+d/lsY4MYizRRs6slQlm3Vd1fBOC2ztVWYQJb/xGmrBi 8PWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c95si902117otb.296.2020.04.09.00.46.10; Thu, 09 Apr 2020 00:46:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726597AbgDIHp0 (ORCPT + 99 others); Thu, 9 Apr 2020 03:45:26 -0400 Received: from asavdk3.altibox.net ([109.247.116.14]:44662 "EHLO asavdk3.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725783AbgDIHp0 (ORCPT ); Thu, 9 Apr 2020 03:45:26 -0400 Received: from ravnborg.org (unknown [158.248.194.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk3.altibox.net (Postfix) with ESMTPS id C927020029; Thu, 9 Apr 2020 09:45:13 +0200 (CEST) Date: Thu, 9 Apr 2020 09:45:07 +0200 From: Sam Ravnborg To: Mateusz Holenko Cc: Rob Herring , Mark Rutland , Greg Kroah-Hartman , Jiri Slaby , devicetree@vger.kernel.org, linux-serial@vger.kernel.org, Stafford Horne , Karol Gugala , Mauro Carvalho Chehab , "David S. Miller" , "Paul E. McKenney" , Filip Kokosinski , Pawel Czarnecki , Joel Stanley , Jonathan Cameron , Maxime Ripard , Shawn Guo , Heiko Stuebner , Icenowy Zheng , Laurent Pinchart , linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 3/5] drivers/soc/litex: add LiteX SoC Controller driver Message-ID: <20200409074507.GA15724@ravnborg.org> References: <20200402084513.4173306-0-mholenko@antmicro.com> <20200402084513.4173306-3-mholenko@antmicro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200402084513.4173306-3-mholenko@antmicro.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=eMA9ckh1 c=1 sm=1 tr=0 a=UWs3HLbX/2nnQ3s7vZ42gw==:117 a=UWs3HLbX/2nnQ3s7vZ42gw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=ZX33tajJAAAA:8 a=20KFwNOVAAAA:8 a=coVbaYRRAAAA:20 a=RabjGhs-xBbIAaBAO2wA:9 a=CjuIK1q_8ugA:10 a=L5i5bogn6ywA:10 a=n1A84ZsOX-pFaLrW-s9c:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mateusz A few drive-by comments - the soc area is not something I am well versed in. Sam On Thu, Apr 02, 2020 at 08:46:10AM +0200, Mateusz Holenko wrote: > From: Pawel Czarnecki > > This commit adds driver for the FPGA-based LiteX SoC > Controller from LiteX SoC builder. > > Co-developed-by: Mateusz Holenko > Signed-off-by: Mateusz Holenko > Signed-off-by: Pawel Czarnecki > --- > > Notes: > Changes in v4: > - fixed indent in Kconfig's help section > - fixed copyright header > - changed compatible to "litex,soc-controller" > - simplified litex_soc_ctrl_probe > - removed unnecessary litex_soc_ctrl_remove > > This commit has been introduced in v3 of the patchset. > > It includes a simplified version of common 'litex.h' > header introduced in v2 of the patchset. > > MAINTAINERS | 2 + > drivers/soc/Kconfig | 1 + > drivers/soc/Makefile | 1 + > drivers/soc/litex/Kconfig | 14 ++ > drivers/soc/litex/Makefile | 3 + > drivers/soc/litex/litex_soc_ctrl.c | 217 +++++++++++++++++++++++++++++ > include/linux/litex.h | 45 ++++++ > 7 files changed, 283 insertions(+) > create mode 100644 drivers/soc/litex/Kconfig > create mode 100644 drivers/soc/litex/Makefile > create mode 100644 drivers/soc/litex/litex_soc_ctrl.c > create mode 100644 include/linux/litex.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 2f5ede8a08aa..a35be1be90d5 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -9729,6 +9729,8 @@ M: Karol Gugala > M: Mateusz Holenko > S: Maintained > F: Documentation/devicetree/bindings/*/litex,*.yaml > +F: drivers/soc/litex/litex_soc_ctrl.c > +F: include/linux/litex.h > > LIVE PATCHING > M: Josh Poimboeuf > diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig > index 1778f8c62861..78add2a163be 100644 > --- a/drivers/soc/Kconfig > +++ b/drivers/soc/Kconfig > @@ -9,6 +9,7 @@ source "drivers/soc/bcm/Kconfig" > source "drivers/soc/fsl/Kconfig" > source "drivers/soc/imx/Kconfig" > source "drivers/soc/ixp4xx/Kconfig" > +source "drivers/soc/litex/Kconfig" > source "drivers/soc/mediatek/Kconfig" > source "drivers/soc/qcom/Kconfig" > source "drivers/soc/renesas/Kconfig" > diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile > index 8b49d782a1ab..fd016b51cddd 100644 > --- a/drivers/soc/Makefile > +++ b/drivers/soc/Makefile > @@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_GEMINI) += gemini/ > obj-$(CONFIG_ARCH_MXC) += imx/ > obj-$(CONFIG_ARCH_IXP4XX) += ixp4xx/ > obj-$(CONFIG_SOC_XWAY) += lantiq/ > +obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex/ > obj-y += mediatek/ > obj-y += amlogic/ > obj-y += qcom/ > diff --git a/drivers/soc/litex/Kconfig b/drivers/soc/litex/Kconfig > new file mode 100644 > index 000000000000..71264c0e1d6c > --- /dev/null > +++ b/drivers/soc/litex/Kconfig > @@ -0,0 +1,14 @@ > +# SPDX-License_Identifier: GPL-2.0 > + > +menu "Enable LiteX SoC Builder specific drivers" > + > +config LITEX_SOC_CONTROLLER > + tristate "Enable LiteX SoC Controller driver" > + help > + This option enables the SoC Controller Driver which verifies > + LiteX CSR access and provides common litex_get_reg/litex_set_reg > + accessors. > + All drivers that use functions from litex.h must depend on > + LITEX_SOC_CONTROLLER. > + > +endmenu > diff --git a/drivers/soc/litex/Makefile b/drivers/soc/litex/Makefile > new file mode 100644 > index 000000000000..98ff7325b1c0 > --- /dev/null > +++ b/drivers/soc/litex/Makefile > @@ -0,0 +1,3 @@ > +# SPDX-License_Identifier: GPL-2.0 > + > +obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex_soc_ctrl.o > diff --git a/drivers/soc/litex/litex_soc_ctrl.c b/drivers/soc/litex/litex_soc_ctrl.c > new file mode 100644 > index 000000000000..5defba000fd4 > --- /dev/null > +++ b/drivers/soc/litex/litex_soc_ctrl.c > @@ -0,0 +1,217 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * LiteX SoC Controller Driver > + * > + * Copyright (C) 2020 Antmicro > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* > + * The parameters below are true for LiteX SoC > + * configured for 8-bit CSR Bus, 32-bit aligned. > + * > + * Supporting other configurations will require > + * extending the logic in this header. > + */ > +#define LITEX_REG_SIZE 0x4 > +#define LITEX_SUBREG_SIZE 0x1 > +#define LITEX_SUBREG_SIZE_BIT (LITEX_SUBREG_SIZE * 8) > + > +static DEFINE_SPINLOCK(csr_lock); > + > +static inline unsigned long read_pointer_with_barrier( > + const volatile void __iomem *addr) > +{ > + unsigned long val; > + > + __io_br(); > + val = *(const volatile unsigned long __force *)addr; > + __io_ar(); > + return val; > +} This looks like an open-oced version of readl() See include/asm-generic/io.h > + > +static inline void write_pointer_with_barrier( > + volatile void __iomem *addr, unsigned long val) > +{ > + __io_br(); > + *(volatile unsigned long __force *)addr = val; > + __io_ar(); > +} Likewise. > + > +/* > + * LiteX SoC Generator, depending on the configuration, > + * can split a single logical CSR (Control & Status Register) > + * into a series of consecutive physical registers. > + * > + * For example, in the configuration with 8-bit CSR Bus, > + * 32-bit aligned (the default one for 32-bit CPUs) a 32-bit > + * logical CSR will be generated as four 32-bit physical registers, > + * each one containing one byte of meaningful data. > + * > + * For details see: https://github.com/enjoy-digital/litex/issues/314 > + * > + * The purpose of `litex_set_reg`/`litex_get_reg` is to implement > + * the logic of writing to/reading from the LiteX CSR in a single > + * place that can be then reused by all LiteX drivers. > + */ > +void litex_set_reg( > + void __iomem *reg, unsigned long reg_size, unsigned long val) > +{ The typical linux style is: void litex_set_reg(void __iomem *reg, unsigned long reg_size, unsigned long val) { And if the line is too long, then aling with tabs+spaces right after first opening paranthese. General comment for the remaining of the file. > + unsigned long shifted_data, shift, i; > + unsigned long flags; > + > + spin_lock_irqsave(&csr_lock, flags); > + > + for (i = 0; i < reg_size; ++i) { > + shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT); > + shifted_data = val >> shift; > + write_pointer_with_barrier( > + reg + (LITEX_REG_SIZE * i), shifted_data); > + } > + > + spin_unlock_irqrestore(&csr_lock, flags); > +} > + > +unsigned long litex_get_reg( > + void __iomem *reg, unsigned long reg_size) > +{ > + unsigned long shifted_data, shift, i; > + unsigned long result = 0; > + unsigned long flags; > + > + spin_lock_irqsave(&csr_lock, flags); > + > + for (i = 0; i < reg_size; ++i) { > + shifted_data = read_pointer_with_barrier( > + reg + (LITEX_REG_SIZE * i)); > + shift = ((reg_size - i - 1) * LITEX_SUBREG_SIZE_BIT); > + result |= (shifted_data << shift); > + } > + > + spin_unlock_irqrestore(&csr_lock, flags); > + > + return result; > +} > + > +static int accessors_ok; > + > +/* > + * Check if accessors are safe to be used by other drivers > + * returns true if yes - false if not > + */ > +int litex_check_accessors(void) > +{ > + return accessors_ok; > +} > + > +#define SCRATCH_REG_OFF 0x04 > +#define SCRATCH_REG_SIZE 4 > +#define SCRATCH_REG_VALUE 0x12345678 > +#define SCRATCH_TEST_VALUE 0xdeadbeef > + > +/* > + * Check LiteX CSR read/write access > + * > + * This function reads and writes a scratch register in order > + * to verify if CSR access works. > + * > + * In case any problems are detected, the driver should panic > + * and not set `accessors_ok` flag. As a result no other > + * LiteX driver should access CSR bus. > + * > + * Access to the LiteX CSR is, by design, done in CPU native > + * endianness. The driver should not dynamically configure > + * access functions when the endianness mismatch is detected. > + * Such situation indicates problems in the soft SoC design > + * and should be solved at the LiteX generator level, > + * not in the software. > + */ > +static int litex_check_csr_access(void __iomem *reg_addr) > +{ > + unsigned long reg; > + > + reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE); > + > + if (reg != SCRATCH_REG_VALUE) { > + panic("Scratch register read error! Expected: 0x%x but got: 0x%lx", > + SCRATCH_REG_VALUE, reg); > + return -EINVAL; > + } > + > + litex_set_reg(reg_addr + SCRATCH_REG_OFF, > + SCRATCH_REG_SIZE, SCRATCH_TEST_VALUE); > + reg = litex_get_reg(reg_addr + SCRATCH_REG_OFF, SCRATCH_REG_SIZE); > + > + if (reg != SCRATCH_TEST_VALUE) { > + panic("Scratch register write error! Expected: 0x%x but got: 0x%lx", > + SCRATCH_TEST_VALUE, reg); > + return -EINVAL; > + } > + > + /* restore original value of the SCRATCH register */ > + litex_set_reg(reg_addr + SCRATCH_REG_OFF, > + SCRATCH_REG_SIZE, SCRATCH_REG_VALUE); > + > + /* Set flag for other drivers */ > + accessors_ok = 1; > + pr_info("LiteX SoC Controller driver initialized"); > + > + return 0; > +} > + > +struct litex_soc_ctrl_device { > + void __iomem *base; > +}; > + > +static const struct of_device_id litex_soc_ctrl_of_match[] = { > + {.compatible = "litex,soc-controller"}, > + {}, > +}; > + > +MODULE_DEVICE_TABLE(of, litex_soc_ctrl_of_match); > + > +static int litex_soc_ctrl_probe(struct platform_device *pdev) > +{ > + struct device *dev; > + struct device_node *node; > + struct litex_soc_ctrl_device *soc_ctrl_dev; > + > + dev = &pdev->dev; > + node = dev->of_node; > + if (!node) > + return -ENODEV; > + > + soc_ctrl_dev = devm_kzalloc(dev, sizeof(*soc_ctrl_dev), GFP_KERNEL); > + if (IS_ERR_OR_NULL(soc_ctrl_dev)) > + return -ENOMEM; devm_kzalloc() either return NULL or allocated memory. No need to do IS_ERR_OR_NULL() > + > + soc_ctrl_dev->base = devm_platform_ioremap_resource(pdev, 0); > + if (IS_ERR_OR_NULL(soc_ctrl_dev->base)) > + return -EIO; devm_platform_ioremap_resource does not return NUL on error. So you loose the original error code here. Sam > + > + return litex_check_csr_access(soc_ctrl_dev->base); > +} > + > +static struct platform_driver litex_soc_ctrl_driver = { > + .driver = { > + .name = "litex-soc-controller", > + .of_match_table = of_match_ptr(litex_soc_ctrl_of_match) > + }, > + .probe = litex_soc_ctrl_probe, > +}; > + > +module_platform_driver(litex_soc_ctrl_driver); > +MODULE_DESCRIPTION("LiteX SoC Controller driver"); > +MODULE_AUTHOR("Antmicro "); > +MODULE_LICENSE("GPL v2"); > diff --git a/include/linux/litex.h b/include/linux/litex.h > new file mode 100644 > index 000000000000..f31062436273 > --- /dev/null > +++ b/include/linux/litex.h > @@ -0,0 +1,45 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Common LiteX header providing > + * helper functions for accessing CSRs. > + * > + * Implementation of the functions is provided by > + * the LiteX SoC Controller driver. > + * > + * Copyright (C) 2019-2020 Antmicro > + */ > + > +#ifndef _LINUX_LITEX_H > +#define _LINUX_LITEX_H > + > +#include > +#include > +#include > + > +/* > + * litex_check_accessors is a function implemented in > + * drivers/soc/litex/litex_soc_controller.c > + * checking if the common LiteX CSR accessors > + * are safe to be used by the drivers; > + * returns true (1) if yes - false (0) if not > + * > + * Important: All drivers that use litex_set_reg/litex_get_reg > + * functions should make sure that LiteX SoC Controller driver > + * has verified LiteX CSRs read and write operations before > + * issuing any read/writes to the LiteX peripherals. > + * > + * Exemplary snippet that can be used at the beginning > + * of the driver's probe() function to ensure that LiteX > + * SoC Controller driver is properely initialized: > + * > + * if (!litex_check_accessors()) > + * return -EPROBE_DEFER; > + */ > +int litex_check_accessors(void); > + > +void litex_set_reg(void __iomem *reg, unsigned long reg_sz, unsigned long val); > + > +unsigned long litex_get_reg(void __iomem *reg, unsigned long reg_sz); > + > + > +#endif /* _LINUX_LITEX_H */ > -- > 2.25.1