From: Jacky Huang <ychuang570808@gmail.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
lee@kernel.org, mturquette@baylibre.com, sboyd@kernel.org,
gregkh@linuxfoundation.org, jirislaby@kernel.org,
devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
arnd@arndb.de, schung@nuvoton.com, mjchen@nuvoton.com,
Jacky Huang <ychuang3@nuvoton.com>
Subject: Re: [PATCH v7 10/12] reset: Add Nuvoton ma35d1 reset driver support
Date: Tue, 25 Apr 2023 09:30:58 +0800 [thread overview]
Message-ID: <4e1cd1c7-e681-fb25-1dcf-16d68e5e525b@gmail.com> (raw)
In-Reply-To: <20230424192137.GB30248@pengutronix.de>
On 2023/4/25 上午 03:21, Philipp Zabel wrote:
> Hi Jacky,
>
> On Wed, Apr 12, 2023 at 05:38:22AM +0000, Jacky Huang wrote:
>> From: Jacky Huang <ychuang3@nuvoton.com>
>>
>> This driver supports individual IP reset for ma35d1. The reset
>> control registers is a subset of system control registers.
>>
>> Signed-off-by: Jacky Huang <ychuang3@nuvoton.com>
>> ---
>> drivers/reset/Kconfig | 6 +
>> drivers/reset/Makefile | 1 +
>> drivers/reset/reset-ma35d1.c | 255 +++++++++++++++++++++++++++++++++++
>> 3 files changed, 262 insertions(+)
>> create mode 100644 drivers/reset/reset-ma35d1.c
>>
>> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
>> index 2a52c990d4fe..58477c6ca9b8 100644
>> --- a/drivers/reset/Kconfig
>> +++ b/drivers/reset/Kconfig
>> @@ -143,6 +143,12 @@ config RESET_NPCM
>> This enables the reset controller driver for Nuvoton NPCM
>> BMC SoCs.
>>
>> +config RESET_NUVOTON_MA35D1
>> + bool "Nuvton MA35D1 Reset Driver"
>> + default ARCH_NUVOTON || COMPILE_TEST
>> + help
>> + This enables the reset controller driver for Nuvoton MA35D1 SoC.
>> +
>> config RESET_OXNAS
>> bool
>>
>> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
>> index 3e7e5fd633a8..fd52dcf66a99 100644
>> --- a/drivers/reset/Makefile
>> +++ b/drivers/reset/Makefile
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_RESET_MCHP_SPARX5) += reset-microchip-sparx5.o
>> obj-$(CONFIG_RESET_MESON) += reset-meson.o
>> obj-$(CONFIG_RESET_MESON_AUDIO_ARB) += reset-meson-audio-arb.o
>> obj-$(CONFIG_RESET_NPCM) += reset-npcm.o
>> +obj-$(CONFIG_RESET_NUVOTON_MA35D1) += reset-ma35d1.o
>> obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
>> obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
>> obj-$(CONFIG_RESET_POLARFIRE_SOC) += reset-mpfs.o
>> diff --git a/drivers/reset/reset-ma35d1.c b/drivers/reset/reset-ma35d1.c
>> new file mode 100644
>> index 000000000000..57ed710c10f4
>> --- /dev/null
>> +++ b/drivers/reset/reset-ma35d1.c
>> @@ -0,0 +1,255 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2023 Nuvoton Technology Corp.
>> + * Author: Chi-Fang Li <cfli0@nuvoton.com>
>> + */
>> +
>> +#include <linux/device.h>
>> +#include <linux/io.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reboot.h>
>> +#include <linux/reset-controller.h>
>> +#include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
>> +
>> +struct ma35d1_reset_data {
>> + struct reset_controller_dev rcdev;
>> + void __iomem *base;
>> +};
>> +
>> +struct ma35d1_reboot_data {
>> + struct notifier_block restart_handler;
>> + void __iomem *base;
>> +};
> These two structs can be combined into one, no need to duplicate the
> iomem base.
Sure, we will combine these two into one structure.
>> +
>> +static const struct {
>> + unsigned long id;
> Why store the id? ids should be contiguous and should start at 0,
> so the id could just be an index into the array.
Thank you, I didn't notice that the IDs were already consecutive.
The id field is indeed unnecessary, and I will remove it.
>> + u32 reg_ofs;
>> + u32 bit;
>> +} ma35d1_reset_map[] = {
>> + { MA35D1_RESET_CHIP, 0x20, 0 },
>> + { MA35D1_RESET_CA35CR0, 0x20, 1 },
>> + { MA35D1_RESET_CA35CR1, 0x20, 2 },
>> + { MA35D1_RESET_CM4, 0x20, 3 },
>> + { MA35D1_RESET_PDMA0, 0x20, 4 },
>> + { MA35D1_RESET_PDMA1, 0x20, 5 },
>> + { MA35D1_RESET_PDMA2, 0x20, 6 },
>> + { MA35D1_RESET_PDMA3, 0x20, 7 },
>> + { MA35D1_RESET_DISP, 0x20, 9 },
>> + { MA35D1_RESET_VCAP0, 0x20, 10 },
>> + { MA35D1_RESET_VCAP1, 0x20, 11 },
>> + { MA35D1_RESET_GFX, 0x20, 12 },
>> + { MA35D1_RESET_VDEC, 0x20, 13 },
>> + { MA35D1_RESET_WHC0, 0x20, 14 },
>> + { MA35D1_RESET_WHC1, 0x20, 15 },
>> + { MA35D1_RESET_GMAC0, 0x20, 16 },
>> + { MA35D1_RESET_GMAC1, 0x20, 17 },
>> + { MA35D1_RESET_HWSEM, 0x20, 18 },
>> + { MA35D1_RESET_EBI, 0x20, 19 },
>> + { MA35D1_RESET_HSUSBH0, 0x20, 20 },
>> + { MA35D1_RESET_HSUSBH1, 0x20, 21 },
>> + { MA35D1_RESET_HSUSBD, 0x20, 22 },
>> + { MA35D1_RESET_USBHL, 0x20, 23 },
>> + { MA35D1_RESET_SDH0, 0x20, 24 },
>> + { MA35D1_RESET_SDH1, 0x20, 25 },
>> + { MA35D1_RESET_NAND, 0x20, 26 },
>> + { MA35D1_RESET_GPIO, 0x20, 27 },
>> + { MA35D1_RESET_MCTLP, 0x20, 28 },
>> + { MA35D1_RESET_MCTLC, 0x20, 29 },
>> + { MA35D1_RESET_DDRPUB, 0x20, 30 },
>> + { MA35D1_RESET_TMR0, 0x24, 2 },
>> + { MA35D1_RESET_TMR1, 0x24, 3 },
>> + { MA35D1_RESET_TMR2, 0x24, 4 },
>> + { MA35D1_RESET_TMR3, 0x24, 5 },
>> + { MA35D1_RESET_I2C0, 0x24, 8 },
>> + { MA35D1_RESET_I2C1, 0x24, 9 },
>> + { MA35D1_RESET_I2C2, 0x24, 10 },
>> + { MA35D1_RESET_I2C3, 0x24, 11 },
>> + { MA35D1_RESET_QSPI0, 0x24, 12 },
>> + { MA35D1_RESET_SPI0, 0x24, 13 },
>> + { MA35D1_RESET_SPI1, 0x24, 14 },
>> + { MA35D1_RESET_SPI2, 0x24, 15 },
>> + { MA35D1_RESET_UART0, 0x24, 16 },
>> + { MA35D1_RESET_UART1, 0x24, 17 },
>> + { MA35D1_RESET_UART2, 0x24, 18 },
>> + { MA35D1_RESET_UAER3, 0x24, 19 },
>> + { MA35D1_RESET_UART4, 0x24, 20 },
>> + { MA35D1_RESET_UART5, 0x24, 21 },
>> + { MA35D1_RESET_UART6, 0x24, 22 },
>> + { MA35D1_RESET_UART7, 0x24, 23 },
>> + { MA35D1_RESET_CANFD0, 0x24, 24 },
>> + { MA35D1_RESET_CANFD1, 0x24, 25 },
>> + { MA35D1_RESET_EADC0, 0x24, 28 },
>> + { MA35D1_RESET_I2S0, 0x24, 29 },
>> + { MA35D1_RESET_SC0, 0x28, 0 },
>> + { MA35D1_RESET_SC1, 0x28, 1 },
>> + { MA35D1_RESET_QSPI1, 0x28, 4 },
>> + { MA35D1_RESET_SPI3, 0x28, 6 },
>> + { MA35D1_RESET_EPWM0, 0x28, 16 },
>> + { MA35D1_RESET_EPWM1, 0x28, 17 },
>> + { MA35D1_RESET_QEI0, 0x28, 22 },
>> + { MA35D1_RESET_QEI1, 0x28, 23 },
>> + { MA35D1_RESET_ECAP0, 0x28, 26 },
>> + { MA35D1_RESET_ECAP1, 0x28, 27 },
>> + { MA35D1_RESET_CANFD2, 0x28, 28 },
>> + { MA35D1_RESET_ADC0, 0x28, 31 },
>> + { MA35D1_RESET_TMR4, 0x2C, 0 },
>> + { MA35D1_RESET_TMR5, 0x2C, 1 },
>> + { MA35D1_RESET_TMR6, 0x2C, 2 },
>> + { MA35D1_RESET_TMR7, 0x2C, 3 },
>> + { MA35D1_RESET_TMR8, 0x2C, 4 },
>> + { MA35D1_RESET_TMR9, 0x2C, 5 },
>> + { MA35D1_RESET_TMR10, 0x2C, 6 },
>> + { MA35D1_RESET_TMR11, 0x2C, 7 },
>> + { MA35D1_RESET_UART8, 0x2C, 8 },
>> + { MA35D1_RESET_UART9, 0x2C, 9 },
>> + { MA35D1_RESET_UART10, 0x2C, 10 },
>> + { MA35D1_RESET_UART11, 0x2C, 11 },
>> + { MA35D1_RESET_UART12, 0x2C, 12 },
>> + { MA35D1_RESET_UART13, 0x2C, 13 },
>> + { MA35D1_RESET_UART14, 0x2C, 14 },
>> + { MA35D1_RESET_UART15, 0x2C, 15 },
>> + { MA35D1_RESET_UART16, 0x2C, 16 },
>> + { MA35D1_RESET_I2S1, 0x2C, 17 },
>> + { MA35D1_RESET_I2C4, 0x2C, 18 },
>> + { MA35D1_RESET_I2C5, 0x2C, 19 },
>> + { MA35D1_RESET_EPWM2, 0x2C, 20 },
>> + { MA35D1_RESET_ECAP2, 0x2C, 21 },
>> + { MA35D1_RESET_QEI2, 0x2C, 22 },
>> + { MA35D1_RESET_CANFD3, 0x2C, 23 },
>> + { MA35D1_RESET_KPI, 0x2C, 24 },
>> + { MA35D1_RESET_GIC, 0x2C, 28 },
>> + { MA35D1_RESET_SSMCC, 0x2C, 30 },
>> + { MA35D1_RESET_SSPCC, 0x2C, 31 }
>> +};
>> +
>> +static u32 ma35d1_reset_map_lookup(unsigned long id)
>> +{
>> + u32 i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(ma35d1_reset_map); i++) {
>> + if (ma35d1_reset_map[i].id == id)
>> + break;
>> + }
>> + return i;
>> +}
> If you use the id as a look up into the mapping array, this lookup
> function wouldn't be necessary.
Yes, it's not necessary. I will modify it.
>> +static int ma35d1_restart_handler(struct notifier_block *this,
>> + unsigned long mode, void *cmd)
>> +{
>> + u32 i;
>> + struct ma35d1_reboot_data *data = container_of(this,
>> + struct ma35d1_reboot_data,
>> + restart_handler);
>> +
>> + i = ma35d1_reset_map_lookup(MA35D1_RESET_CHIP);
>> + writel_relaxed(BIT(ma35d1_reset_map[i].bit),
>> + data->base + ma35d1_reset_map[i].reg_ofs);
>> + return 0;
>> +}
>> +
>> +static int ma35d1_reset_update(struct reset_controller_dev *rcdev,
>> + unsigned long id, bool assert)
>> +{
>> + u32 i, reg;
>> + struct ma35d1_reset_data *data = container_of(rcdev,
>> + struct ma35d1_reset_data,
>> + rcdev);
>> +
>> + i = ma35d1_reset_map_lookup(id);
>> + reg = readl_relaxed(data->base + ma35d1_reset_map[i].reg_ofs);
>> + if (assert)
>> + reg |= BIT(ma35d1_reset_map[i].bit);
>> + else
>> + reg &= ~(BIT(ma35d1_reset_map[i].bit));
>> + writel_relaxed(reg, data->base + ma35d1_reset_map[i].reg_ofs);
> This requires a spinlock to protect the register from simultaneous
> read-modify-writes.
OK, I will add spinlock protect for it.
> [...]
>> +static int ma35d1_reset_probe(struct platform_device *pdev)
>> +{
>> + int err;
>> + struct device *dev = &pdev->dev;
>> + struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + struct ma35d1_reset_data *reset_data;
>> + struct ma35d1_reboot_data *reboot_data;
>> +
>> + if (!pdev->dev.of_node) {
>> + dev_err(&pdev->dev, "Device tree node not found\n");
> The driver is only probed via OF, so this isn't reachable and can be
> dropped.
Okay, I will remove this check.
> regards
> Philipp
Thank you for the comments.
Best regards,
Jacky Huang
next prev parent reply other threads:[~2023-04-25 1:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 5:38 [PATCH v7 00/12] Introduce Nuvoton ma35d1 SoC Jacky Huang
2023-04-12 5:38 ` [PATCH v7 01/12] arm64: Kconfig.platforms: Add config for Nuvoton MA35 platform Jacky Huang
2023-04-12 5:38 ` [PATCH v7 02/12] arm64: defconfig: Add support for Nuvoton MA35 family SoCs Jacky Huang
2023-04-12 5:38 ` [PATCH v7 03/12] dt-bindings: clock: nuvoton: add binding for ma35d1 clock controller Jacky Huang
2023-04-12 5:38 ` [PATCH v7 04/12] dt-bindings: reset: nuvoton: Document ma35d1 reset control Jacky Huang
2023-04-13 16:58 ` Krzysztof Kozlowski
2023-04-14 0:55 ` Jacky Huang
2023-04-14 7:46 ` Krzysztof Kozlowski
2023-04-14 8:27 ` Jacky Huang
2023-04-13 20:21 ` Stephen Boyd
2023-04-14 1:29 ` Jacky Huang
2023-04-12 5:38 ` [PATCH v7 05/12] dt-bindings: mfd: syscon: Add nuvoton,ma35d1-sys compatible Jacky Huang
2023-04-13 16:47 ` Krzysztof Kozlowski
2023-04-14 1:11 ` Jacky Huang
2023-04-14 7:03 ` Lee Jones
2023-04-14 8:34 ` Jacky Huang
2023-04-19 15:37 ` Lee Jones
2023-04-12 5:38 ` [PATCH v7 06/12] dt-bindings: arm: Add initial bindings for Nuvoton platform Jacky Huang
2023-04-13 17:01 ` Krzysztof Kozlowski
2023-04-14 1:27 ` Jacky Huang
2023-04-12 5:38 ` [PATCH v7 07/12] dt-bindings: serial: Document ma35d1 uart controller Jacky Huang
2023-04-12 5:38 ` [PATCH v7 08/12] arm64: dts: nuvoton: Add initial ma35d1 device tree Jacky Huang
2023-04-12 5:38 ` [PATCH v7 09/12] clk: nuvoton: Add clock driver for ma35d1 clock controller Jacky Huang
2023-04-13 20:27 ` Stephen Boyd
2023-04-15 3:58 ` Jacky Huang
2023-04-18 20:23 ` Stephen Boyd
2023-04-19 0:32 ` Jacky Huang
2023-04-12 5:38 ` [PATCH v7 10/12] reset: Add Nuvoton ma35d1 reset driver support Jacky Huang
2023-04-24 19:21 ` Philipp Zabel
2023-04-25 1:30 ` Jacky Huang [this message]
2023-04-25 7:40 ` Ilpo Järvinen
2023-04-25 8:07 ` Jacky Huang
2023-04-12 5:38 ` [PATCH v7 11/12] tty: serial: Add Nuvoton ma35d1 serial " Jacky Huang
2023-04-14 6:47 ` Jiri Slaby
2023-04-16 2:31 ` Jacky Huang
2023-04-19 3:43 ` kernel test robot
2023-04-12 5:38 ` [PATCH v7 12/12] MAINTAINERS: Add entry for NUVOTON MA35 Jacky Huang
2023-04-13 17:01 ` Krzysztof Kozlowski
2023-04-14 1:22 ` Jacky Huang
2023-04-14 7:46 ` Krzysztof Kozlowski
2023-04-14 9:04 ` Jacky Huang
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=4e1cd1c7-e681-fb25-1dcf-16d68e5e525b@gmail.com \
--to=ychuang570808@gmail.com \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee@kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=mjchen@nuvoton.com \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=schung@nuvoton.com \
--cc=ychuang3@nuvoton.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).