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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.