[v6,1/2] soc: loongson: add GUTS driver for loongson-2 platforms

  The global utilities block controls PCIE device enabling, alternate
function selection for multiplexed signals, consistency of HDA, USB
and PCIE, configuration of memory controller, rtc controller, lio
controller, and clock control.

This patch adds a driver to manage and access global utilities block
for loongarch architecture Loongson-2 SoCs. Initially only reading SVR
and registering soc device are supported. Other guts accesses, such
as reading PMON configuration by default, should eventually be added
into this driver as well.

Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
---
Change in v6:
		1. Add full name spelling about GUTS in Kconfig.
		2. Add reviewed-by information.
Change in v5:
		1. Add all history change log information.
Change in v4:
		1. Remove menu information in Kconfig.
Change in v3:
		1. Replace string loongson2/Loongson2 with Loongson-2/loongson-2
	           in commit message, Kconfig, Makefile file.
		2. Replace string LOONGSON2 with LOONGSON-2.
Change in v2:
		1. Add architecture support commit log description.
		2. Add other guts accesses plan commit log description.
		3. Add "depends on LOONGARCH || COMPILE_TEST" for
		   LOONGSON2_GUTS in Kconfig.
		4. Move the scfg_guts to .c file from .h and delete .h.
		5. Remove __packed on scfg_guts.

 MAINTAINERS                           |   6 +
 drivers/soc/Kconfig                   |   1 +
 drivers/soc/Makefile                  |   1 +
 drivers/soc/loongson/Kconfig          |  18 +++
 drivers/soc/loongson/Makefile         |   6 +
 drivers/soc/loongson/loongson2_guts.c | 189 ++++++++++++++++++++++++++
 6 files changed, 221 insertions(+)
 create mode 100644 drivers/soc/loongson/Kconfig
 create mode 100644 drivers/soc/loongson/Makefile
 create mode 100644 drivers/soc/loongson/loongson2_guts.c
  

Hi maintainer,

This patch I had verified that base on mainline 6.1-rc3 tree, it is
okay, if no other issue, please you help me merge it to upstream.

Thanks,
Yinbo.

在 2022/11/4 上午10:48, Yinbo Zhu 写道:
> The global utilities block controls PCIE device enabling, alternate
> function selection for multiplexed signals, consistency of HDA, USB
> and PCIE, configuration of memory controller, rtc controller, lio
> controller, and clock control.
> 
> This patch adds a driver to manage and access global utilities block
> for loongarch architecture Loongson-2 SoCs. Initially only reading SVR
> and registering soc device are supported. Other guts accesses, such
> as reading PMON configuration by default, should eventually be added
> into this driver as well.
> 
> Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> ---
> Change in v6:
> 		1. Add full name spelling about GUTS in Kconfig.
> 		2. Add reviewed-by information.
> Change in v5:
> 		1. Add all history change log information.
> Change in v4:
> 		1. Remove menu information in Kconfig.
> Change in v3:
> 		1. Replace string loongson2/Loongson2 with Loongson-2/loongson-2
> 	           in commit message, Kconfig, Makefile file.
> 		2. Replace string LOONGSON2 with LOONGSON-2.
> Change in v2:
> 		1. Add architecture support commit log description.
> 		2. Add other guts accesses plan commit log description.
> 		3. Add "depends on LOONGARCH || COMPILE_TEST" for
> 		   LOONGSON2_GUTS in Kconfig.
> 		4. Move the scfg_guts to .c file from .h and delete .h.
> 		5. Remove __packed on scfg_guts.
> 
>   MAINTAINERS                           |   6 +
>   drivers/soc/Kconfig                   |   1 +
>   drivers/soc/Makefile                  |   1 +
>   drivers/soc/loongson/Kconfig          |  18 +++
>   drivers/soc/loongson/Makefile         |   6 +
>   drivers/soc/loongson/loongson2_guts.c | 189 ++++++++++++++++++++++++++
>   6 files changed, 221 insertions(+)
>   create mode 100644 drivers/soc/loongson/Kconfig
>   create mode 100644 drivers/soc/loongson/Makefile
>   create mode 100644 drivers/soc/loongson/loongson2_guts.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c9dc5ddbd9fe..20ce056ae207 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12041,6 +12041,12 @@ S:	Maintained
>   F:	Documentation/devicetree/bindings/pinctrl/loongson,ls2k-pinctrl.yaml
>   F:	drivers/pinctrl/pinctrl-loongson2.c
>   
> +LOONGSON-2 SOC SERIES GUTS DRIVER
> +M:	Yinbo Zhu <zhuyinbo@loongson.cn>
> +L:	loongarch@lists.linux.dev
> +S:	Maintained
> +F:	drivers/soc/loongson/loongson2_guts.c
> +
>   LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
>   M:	Sathya Prakash <sathya.prakash@broadcom.com>
>   M:	Sreekanth Reddy <sreekanth.reddy@broadcom.com>
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index e461c071189b..5dbb09f843f7 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -13,6 +13,7 @@ source "drivers/soc/fujitsu/Kconfig"
>   source "drivers/soc/imx/Kconfig"
>   source "drivers/soc/ixp4xx/Kconfig"
>   source "drivers/soc/litex/Kconfig"
> +source "drivers/soc/loongson/Kconfig"
>   source "drivers/soc/mediatek/Kconfig"
>   source "drivers/soc/microchip/Kconfig"
>   source "drivers/soc/pxa/Kconfig"
> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
> index 69ba6508cf2c..fff513bd522d 100644
> --- a/drivers/soc/Makefile
> +++ b/drivers/soc/Makefile
> @@ -18,6 +18,7 @@ obj-y				+= imx/
>   obj-y				+= ixp4xx/
>   obj-$(CONFIG_SOC_XWAY)		+= lantiq/
>   obj-$(CONFIG_LITEX_SOC_CONTROLLER) += litex/
> +obj-y				+= loongson/
>   obj-y				+= mediatek/
>   obj-y				+= microchip/
>   obj-y				+= pxa/
> diff --git a/drivers/soc/loongson/Kconfig b/drivers/soc/loongson/Kconfig
> new file mode 100644
> index 000000000000..df52599ae87b
> --- /dev/null
> +++ b/drivers/soc/loongson/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Loongson-2 series SoC drivers
> +#
> +
> +config LOONGSON2_GUTS
> +	tristate "Loongson-2 SoC Global UtiliTieS (GUTS) register block"
> +	depends on LOONGARCH || COMPILE_TEST
> +	select SOC_BUS
> +	help
> +	  The global utilities block controls PCIE device enabling, alternate
> +	  function selection for multiplexed signals, consistency of HDA, USB
> +	  and PCIE, configuration of memory controller, rtc controller, lio
> +	  controller, and clock control. This patch adds a driver to manage
> +	  and access global utilities block for loongarch architecture Loongson-2
> +	  SoCs. Initially only reading SVR and registering soc device are
> +	  supported. Other guts accesses, such as reading PMON configuration by
> +	  default, should eventually be added into this driver as well.
> diff --git a/drivers/soc/loongson/Makefile b/drivers/soc/loongson/Makefile
> new file mode 100644
> index 000000000000..263c486df638
> --- /dev/null
> +++ b/drivers/soc/loongson/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Makefile for the Linux Kernel SoC Loongson-2 specific device drivers
> +#
> +
> +obj-$(CONFIG_LOONGSON2_GUTS)		+= loongson2_guts.o
> diff --git a/drivers/soc/loongson/loongson2_guts.c b/drivers/soc/loongson/loongson2_guts.c
> new file mode 100644
> index 000000000000..8f3d5465c7e8
> --- /dev/null
> +++ b/drivers/soc/loongson/loongson2_guts.c
> @@ -0,0 +1,189 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Author: Yinbo Zhu <zhuyinbo@loongson.cn>
> + * Copyright (C) 2022-2023 Loongson Technology Corporation Limited
> + */
> +
> +#include <linux/io.h>
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/of_fdt.h>
> +#include <linux/sys_soc.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +static struct soc_device_attribute soc_dev_attr;
> +static struct soc_device *soc_dev;
> +
> +/*
> + * Global Utility Registers.
> + *
> + * Not all registers defined in this structure are available on all chips, so
> + * you are expected to know whether a given register actually exists on your
> + * chip before you access it.
> + *
> + * Also, some registers are similar on different chips but have slightly
> + * different names.  In these cases, one name is chosen to avoid extraneous
> + * #ifdefs.
> + */
> +struct scfg_guts {
> +	u32     svr;            /* Version Register */
> +	u8      res0[4];
> +	u16     feature;        /* Feature Register */
> +	u32     vendor;         /* Vendor Register */
> +	u8      res1[6];
> +	u32     id;
> +	u8      res2[0x3ff8 - 0x18];
> +	u32     chip;
> +};
> +
> +static struct guts {
> +	struct scfg_guts __iomem *regs;
> +	bool little_endian;
> +} *guts;
> +
> +struct loongson2_soc_die_attr {
> +	char	*die;
> +	u32	svr;
> +	u32	mask;
> +};
> +
> +/* SoC die attribute definition for Loongson-2 platform */
> +static const struct loongson2_soc_die_attr loongson2_soc_die[] = {
> +
> +	/*
> +	 * LA-based SoCs Loongson-2 Series
> +	 */
> +
> +	/* Die: 2k1000la, SoC: 2k1000la */
> +	{ .die		= "2K1000LA",
> +	  .svr		= 0x00000013,
> +	  .mask		= 0x000000ff,
> +	},
> +	{ },
> +};
> +
> +static const struct loongson2_soc_die_attr *loongson2_soc_die_match(
> +	u32 svr, const struct loongson2_soc_die_attr *matches)
> +{
> +	while (matches->svr) {
> +		if (matches->svr == (svr & matches->mask))
> +			return matches;
> +		matches++;
> +	};
> +
> +	return NULL;
> +}
> +
> +static u32 loongson2_guts_get_svr(void)
> +{
> +	u32 svr = 0;
> +
> +	if (!guts || !guts->regs)
> +		return svr;
> +
> +	if (guts->little_endian)
> +		svr = ioread32(&guts->regs->svr);
> +	else
> +		svr = ioread32be(&guts->regs->svr);
> +
> +	return svr;
> +}
> +
> +static int loongson2_guts_probe(struct platform_device *pdev)
> +{
> +	struct device_node *root, *np = pdev->dev.of_node;
> +	struct device *dev = &pdev->dev;
> +	struct resource *res;
> +	const struct loongson2_soc_die_attr *soc_die;
> +	const char *machine;
> +	u32 svr;
> +
> +	/* Initialize guts */
> +	guts = devm_kzalloc(dev, sizeof(*guts), GFP_KERNEL);
> +	if (!guts)
> +		return -ENOMEM;
> +
> +	guts->little_endian = of_property_read_bool(np, "little-endian");
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	guts->regs = ioremap(res->start, res->end - res->start + 1);
> +	if (IS_ERR(guts->regs))
> +		return PTR_ERR(guts->regs);
> +
> +	/* Register soc device */
> +	root = of_find_node_by_path("/");
> +	if (of_property_read_string(root, "model", &machine))
> +		of_property_read_string_index(root, "compatible", 0, &machine);
> +	of_node_put(root);
> +	if (machine)
> +		soc_dev_attr.machine = devm_kstrdup(dev, machine, GFP_KERNEL);
> +
> +	svr = loongson2_guts_get_svr();
> +	soc_die = loongson2_soc_die_match(svr, loongson2_soc_die);
> +	if (soc_die) {
> +		soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL,
> +						     "Loongson %s", soc_die->die);
> +	} else {
> +		soc_dev_attr.family = devm_kasprintf(dev, GFP_KERNEL, "Loongson");
> +	}
> +	if (!soc_dev_attr.family)
> +		return -ENOMEM;
> +	soc_dev_attr.soc_id = devm_kasprintf(dev, GFP_KERNEL,
> +					     "svr:0x%08x", svr);
> +	if (!soc_dev_attr.soc_id)
> +		return -ENOMEM;
> +	soc_dev_attr.revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
> +					       (svr >>  4) & 0xf, svr & 0xf);
> +	if (!soc_dev_attr.revision)
> +		return -ENOMEM;
> +
> +	soc_dev = soc_device_register(&soc_dev_attr);
> +	if (IS_ERR(soc_dev))
> +		return PTR_ERR(soc_dev);
> +
> +	pr_info("Machine: %s\n", soc_dev_attr.machine);
> +	pr_info("SoC family: %s\n", soc_dev_attr.family);
> +	pr_info("SoC ID: %s, Revision: %s\n",
> +		soc_dev_attr.soc_id, soc_dev_attr.revision);
> +
> +	return 0;
> +}
> +
> +static int loongson2_guts_remove(struct platform_device *dev)
> +{
> +	soc_device_unregister(soc_dev);
> +
> +	return 0;
> +}
> +
> +/*
> + * Table for matching compatible strings, for device tree
> + * guts node, for Loongson-2 SoCs.
> + */
> +static const struct of_device_id loongson2_guts_of_match[] = {
> +	{ .compatible = "loongson,ls2k-chipid", },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, loongson2_guts_of_match);
> +
> +static struct platform_driver loongson2_guts_driver = {
> +	.driver = {
> +		.name = "loongson2-guts",
> +		.of_match_table = loongson2_guts_of_match,
> +	},
> +	.probe = loongson2_guts_probe,
> +	.remove = loongson2_guts_remove,
> +};
> +
> +static int __init loongson2_guts_init(void)
> +{
> +	return platform_driver_register(&loongson2_guts_driver);
> +}
> +core_initcall(loongson2_guts_init);
> +
> +static void __exit loongson2_guts_exit(void)
> +{
> +	platform_driver_unregister(&loongson2_guts_driver);
> +}
> +module_exit(loongson2_guts_exit);
>
  

On Wed, Nov 9, 2022 at 11:03 AM Yinbo Zhu <zhuyinbo@loongson.cn> wrote:

> Hi maintainer,
>
> This patch I had verified that base on mainline 6.1-rc3 tree, it is
> okay, if no other issue, please you help me merge it to upstream.

Aren't these loongarch maintainers listed in MAINTAINERS able to
merge this? Certainly Huacai can merge stuff to drivers/soc as
need be. drivers/soc is a bit shared between different archs.

LOONGARCH
M:      Huacai Chen <chenhuacai@kernel.org>
R:      WANG Xuerui <kernel@xen0n.name>
L:      loongarch@lists.linux.dev
S:      Maintained
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git
F:      arch/loongarch/
F:      drivers/*/*loongarch*
F:      Documentation/loongarch/
F:      Documentation/translations/zh_CN/loongarch/

Yours,
Linus Walleij
  

On 09/11/2022 11:15, Linus Walleij wrote:
> On Wed, Nov 9, 2022 at 11:03 AM Yinbo Zhu <zhuyinbo@loongson.cn> wrote:
> 
>> Hi maintainer,
>>
>> This patch I had verified that base on mainline 6.1-rc3 tree, it is
>> okay, if no other issue, please you help me merge it to upstream.
> 
> Aren't these loongarch maintainers listed in MAINTAINERS able to
> merge this? Certainly Huacai can merge stuff to drivers/soc as
> need be. drivers/soc is a bit shared between different archs.

The problem was they were not cc-ed on these patches for some reason.
Maybe the maintainers patterns are incorrect...

Best regards,
Krzysztof
  

On Wed, Nov 9, 2022, at 11:15, Linus Walleij wrote:
> On Wed, Nov 9, 2022 at 11:03 AM Yinbo Zhu <zhuyinbo@loongson.cn> wrote:
>
>> Hi maintainer,
>>
>> This patch I had verified that base on mainline 6.1-rc3 tree, it is
>> okay, if no other issue, please you help me merge it to upstream.
>
> Aren't these loongarch maintainers listed in MAINTAINERS able to
> merge this? Certainly Huacai can merge stuff to drivers/soc as
> need be. drivers/soc is a bit shared between different archs.

I'm generally happy to keep an eye on stuff in drivers/soc/ across
architectures and merge it through the soc tree, especially for
new platforms, but merging this through the loongarch tree works
as well.

Since the driver was already sent to soc@kernel.org, I can
simply pick it up through patchwork[1] when I do my next round
of merges. I'll leave this up to Huacai Chen and WANG Xuerui,
let me know if you prefer to merge it through the loongarch
tree.

    Arnd

[1] https://patchwork.kernel.org/project/linux-soc/list/
  

On Wed, 2022-11-09 at 21:57 +0800, Huacai Chen wrote:
> Hi, Yinbo,
> 
> On Fri, Nov 4, 2022 at 10:48 AM Yinbo Zhu <zhuyinbo@loongson.cn>
> wrote:
> > 
> > The global utilities block controls PCIE device enabling, alternate
> > function selection for multiplexed signals, consistency of HDA, USB
> > and PCIE, configuration of memory controller, rtc controller, lio
> > controller, and clock control.
> > 
> > This patch adds a driver to manage and access global utilities block
> > for loongarch architecture Loongson-2 SoCs. Initially only reading
> > SVR
> Replace loongarch with LoongArch.
> 
> > and registering soc device are supported. Other guts accesses, such
> > as reading PMON configuration by default, should eventually be added
> > into this driver as well.
> Replace PMON with BIOS is better.

Or just "firmware"?  I remember Xuerui (or another guy?) has said
"nobody should use the term BIOS for non-x86 platforms in 2022".
  

On Wed, Nov 9, 2022, at 14:50, Huacai Chen wrote:
> On Wed, Nov 9, 2022 at 7:06 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Nov 9, 2022, at 11:15, Linus Walleij wrote:
>> > On Wed, Nov 9, 2022 at 11:03 AM Yinbo Zhu <zhuyinbo@loongson.cn> wrote:
>> >
>> >> Hi maintainer,
>> >>
>> >> This patch I had verified that base on mainline 6.1-rc3 tree, it is
>> >> okay, if no other issue, please you help me merge it to upstream.
>> >
>> > Aren't these loongarch maintainers listed in MAINTAINERS able to
>> > merge this? Certainly Huacai can merge stuff to drivers/soc as
>> > need be. drivers/soc is a bit shared between different archs.
>>
>> I'm generally happy to keep an eye on stuff in drivers/soc/ across
>> architectures and merge it through the soc tree, especially for
>> new platforms, but merging this through the loongarch tree works
>> as well.
> So drivers/soc is similar to drivers/platform that can be merged
> through corresponding architecture trees?

Right, I think in both cases, there is no top-level subsystem
maintainer, but the rules are specific to the second-level
hierarchy: most parts of drivers/platform/ happen to go
through the x86 platform maintainer trees, and for drivers/soc
we merge most stuff through the soc tree, but a few parts
of each have different maintainers.

>> Since the driver was already sent to soc@kernel.org, I can
>> simply pick it up through patchwork[1] when I do my next round
>> of merges. I'll leave this up to Huacai Chen and WANG Xuerui,
>> let me know if you prefer to merge it through the loongarch
>> tree.
> I'm happy that this series be merged through your linux-arch tree, but
> if it is better (I'm not sure which is better) to go through loongarch
> tree I can also merge it later. However, I have some comments about
> this version. :)

I would prefer the soc tree, and will just apply the
patches from Yinbo Zhu directly this time as I already
have them in my queue. If there are more than a few
drivers/soc/loongarch/ patches in the future, maybe you can
pick them up into a separate branch and forward those
to soc@kernel.org.

Note that I have two separate roles here: I have the
asm-generic tree that I maintain for patches to
include/asm-generic as well as the occasional new
architecture review as I did for loongarch.

The other one is the group maintained soc tree that
is mainly for Arm device tree files, but also contains
soc specific code (arch/arm/mach-*), defconfig files,
drivers (drivers/{soc,firmware,memory,reset}). This is
now extended to arch/riscv and occasionally other
architectures as well, so drivers/soc/loongson fits
well in here.

     Arnd
  

在 2022/11/9 下午11:08, Arnd Bergmann 写道:
> On Wed, Nov 9, 2022, at 14:50, Huacai Chen wrote:
>> On Wed, Nov 9, 2022 at 7:06 PM Arnd Bergmann <arnd@arndb.de> wrote:
>>> On Wed, Nov 9, 2022, at 11:15, Linus Walleij wrote:
>>>> On Wed, Nov 9, 2022 at 11:03 AM Yinbo Zhu <zhuyinbo@loongson.cn> wrote:
>>>>
>>>>> Hi maintainer,
>>>>>
>>>>> This patch I had verified that base on mainline 6.1-rc3 tree, it is
>>>>> okay, if no other issue, please you help me merge it to upstream.
>>>>
>>>> Aren't these loongarch maintainers listed in MAINTAINERS able to
>>>> merge this? Certainly Huacai can merge stuff to drivers/soc as
>>>> need be. drivers/soc is a bit shared between different archs.
>>>
>>> I'm generally happy to keep an eye on stuff in drivers/soc/ across
>>> architectures and merge it through the soc tree, especially for
>>> new platforms, but merging this through the loongarch tree works
>>> as well.
>> So drivers/soc is similar to drivers/platform that can be merged
>> through corresponding architecture trees?
> 
> Right, I think in both cases, there is no top-level subsystem
> maintainer, but the rules are specific to the second-level
> hierarchy: most parts of drivers/platform/ happen to go
> through the x86 platform maintainer trees, and for drivers/soc
> we merge most stuff through the soc tree, but a few parts
> of each have different maintainers.
> 
>>> Since the driver was already sent to soc@kernel.org, I can
>>> simply pick it up through patchwork[1] when I do my next round
>>> of merges. I'll leave this up to Huacai Chen and WANG Xuerui,
>>> let me know if you prefer to merge it through the loongarch
>>> tree.
>> I'm happy that this series be merged through your linux-arch tree, but
>> if it is better (I'm not sure which is better) to go through loongarch
>> tree I can also merge it later. However, I have some comments about
>> this version. :)
> 
> I would prefer the soc tree, and will just apply the
> patches from Yinbo Zhu directly this time as I already
> have them in my queue. If there are more than a few
> drivers/soc/loongarch/ patches in the future, maybe you can
> pick them up into a separate branch and forward those
> to soc@kernel.org.
> 
> Note that I have two separate roles here: I have the
> asm-generic tree that I maintain for patches to
> include/asm-generic as well as the occasional new
> architecture review as I did for loongarch.
> 
> The other one is the group maintained soc tree that
> is mainly for Arm device tree files, but also contains
> soc specific code (arch/arm/mach-*), defconfig files,
> drivers (drivers/{soc,firmware,memory,reset}). This is
> now extended to arch/riscv and occasionally other
> architectures as well, so drivers/soc/loongson fits
> well in here.
> 
>       Arnd
Hi Arnd Bergmann,

I had add v7 version patch and please help check and merge it.
in addition, I don't find apprioate branch in your tree for test, so
my patch was tested that base on 6.1-rc3 master branch.

BRs,
YinBo.
>