* Re: [PATCH v9 00/38] ep93xx device tree conversion
From: Andy Shevchenko @ 2024-03-27 10:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andy Shevchenko, nikita.shubin, Hartley Sweeten,
Alexander Sverdlin, Russell King, Lukasz Majewski, Linus Walleij,
Bartosz Golaszewski, Michael Turquette, Stephen Boyd,
Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Wim Van Sebroeck, Guenter Roeck, Thierry Reding,
Uwe Kleine-König, Mark Brown, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Damien Le Moal, Sergey Shtylyov,
Dmitry Torokhov, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Ralf Baechle, Wu, Aaron, Lee Jones, Olof Johansson, Niklas Cassel,
linux-arm-kernel, linux-kernel, linux-gpio, linux-clk, linux-pm,
devicetree, dmaengine, linux-watchdog, linux-pwm, linux-spi,
netdev, linux-mtd, linux-ide, linux-input, linux-sound,
Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn
In-Reply-To: <a16f45c9-747c-4a19-98a3-aa5f47ee5c4d@linaro.org>
On Wed, Mar 27, 2024 at 7:07 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 26/03/2024 15:49, Andy Shevchenko wrote:
> > On Tue, Mar 26, 2024 at 11:19:54AM +0100, Krzysztof Kozlowski wrote:
> >> On 26/03/2024 10:18, Nikita Shubin via B4 Relay wrote:
...
> >> A lot of this could have been already merged if you split it... Just
> >> saying...
> >
> > But you able to apply DT schema patches if you wish.
> > Just doing? :-)
>
> Me? Why? DT bindings are supposed to go via subsystem maintainers, not
> DT tree.
Okay, I never remembered this rule, thank you for clarifying.
> Plus, I do not apply any bindings patches, except for managed
> subsystems and none of them are touched here.
Good to know!
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-27 10:56 UTC (permalink / raw)
To: krzysztof.kozlowski@linaro.org,
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <038ccb20-71cb-40d2-9720-ce1a0d3eac8c@linaro.org>
On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
> >>>>
> >>> Hi,
> >>>
> >>> I will double check the format of yaml for the next version,
> sorry
> >> for
> >>> inconvenience. But I did test it on mt8188 chromebook, the reason
> >> why
> >>
> >> How do you test a binding on chromebook?
> >>
> >>> power domain need larb node is that when mtcmos power on, signal
> >> glitch
> >>> may produce. Power domain driver must reset larb when this happen
> >> to
> >>> prevent dummy transaction on bus. That why I need larb node in
> dts.
> >>
> >> No one talks here about larb node...
> >
> > Sorry, May you elaborate on what information I need to provide to
> you
> > or it is just a syntax problem I need to fix?
>
> Please explain the purpose of this property (how is it going to be
> used by drivers)and what does it represent.
>
It represent SMI LARB(Local ARBitration). In power domain driver when
power on power domain, It need to reset LARB to prevent potential power
glitch which may cause dummy transaction on bus. Without taking care of
this issue it often leads to camera hang in stress test.
Best Regards,
Yu-chang
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Josua Mayer @ 2024-03-27 10:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <62242f04-c18d-4da0-bd40-1be26886e41a@linaro.org>
Am 27.03.24 um 11:19 schrieb Krzysztof Kozlowski:
> On 26/03/2024 20:26, Josua Mayer wrote:
>> Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski:
>>> On 25/03/2024 21:12, Josua Mayer wrote:
>>>> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski:
>>>>> On 22/03/2024 11:08, Josua Mayer wrote:
>>>>>> Am 21.03.24 um 22:47 schrieb Josua Mayer:
>>>>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on
>>>>>>> CN9130 SoC.
>>>>>>> The carrier boards are identical to the older Armada 388 based Clearfog
>>>>>>> boards. For consistency the carrier part of compatible strings are
>>>>>>> copied, including the established "-a1" suffix.
>>>>>>>
>>>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>>>> ---
>>>>>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++
>>>>>>> 1 file changed, 12 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>>> index 16d2e132d3d1..36bdfd1bedd9 100644
>>>>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>>> @@ -82,4 +82,16 @@ properties:
>>>>>>> - const: marvell,armada-ap807-quad
>>>>>>> - const: marvell,armada-ap807
>>>>>>>
>>>>>>> + - description:
>>>>>>> + SolidRun CN9130 clearfog family single-board computers
>>>>>>> + items:
>>>>>>> + - enum:
>>>>>>> + - solidrun,clearfog-base-a1
>>>>>>> + - solidrun,clearfog-pro-a1
>>>>>>> + - const: solidrun,clearfog-a1
>>>>>>> + - const: solidrun,cn9130-sr-som
>>>>>>> + - const: marvell,cn9130
>>>>>>> + - const: marvell,armada-ap807-quad
>>>>>>> + - const: marvell,armada-ap807
>>>>>>> +
>>>>>>> additionalProperties: true
>>>>>> Before merging I would like some feedback about adding
>>>>>> another product later, to ensure the compatibles above
>>>>>> are adequate? In particular:
>>>>>> - sequence of soc, cp, carrier compatibles
>>>>>> - name of som compatible
>>>>>>
>>>>>> Draft for future bindings:
>>>>>> - description:
>>>>>> SolidRun CN9130 SoM based single-board computers
>>>>>> with 1 external CP on the Carrier.
>>>>>> items:
>>>>>> - enum:
>>>>>> - solidrun,cn9131-solidwan
>>>>>> - const: marvell,cn9131
>>>>>> - const: solidrun,cn9130-sr-som
>>>>> This does not look correct. cn9131 is not compatible with your som.
>>>> This is partially my question.
>>>> I considered changing the som to "cn913x-sr-som".
>>>>
>>>> The SoM itself is always 9130, it contains the base SoC
>>>> with 1x AP and 1x CP in a single chip.
>>>> 9131 and 9132 <happen> on the carrier boards.
>>> No wildcards, but if the SoM name is 9130 then use 9130.
>>> The problem is that you use cn9130 SoC as fallback.
>>>
>>>>>> - const: marvell,cn9130
>>>>> SoCs are compatible only in some cases, e.g. one is a subset of another
>>>>> like stripped out of modem. Are you sure this is your case?
>>>> This is more complex, CN9131 and CN9132 are not single SoCs.
>>>> A "9132" is instantiated by connecting two southbridge chips
>>>> via a Marvell defined bus, each providing additional IO
>>>> such as network, i2c, gpio.
>>>>
>>>> Note that even the first, "9130", while a single chip, contains two dies:
>>>> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c),
>>>> and a "CP" (Communication Processor I assume) with lots of IO.
>>>> This CP as far as I know today is identical to the southbridges
>>>> mentioned above.
>>> OK, but how does it affect compatibility between them? Which parts are
>>> the same? Or how much is shared?
>> 9130, 9131, 9132 belong together.
> I don't understand what it means.
>
>> 9130 is single chip including two dies: AP, CP.
>> The CP is available as an individual chip,
>> up to two can be connected to one 9130.
> And? How does it help me to decide? What is 9131 and 9132?
>
>> What does this mean for compatibility?
>> Which compatibility specifically?
>> Is there a definition we can refer to?
> Devicetree spec.
Let me fetch it for future reference:
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.4
> The compatible property value consists of one or more strings that define the specific programming model for
> the device. This list of strings should be used by a client program for device driver selection. The property
> value consists of a concatenated list of null terminated strings, from most specific to most general. They allow
> a device to express its compatibility with a family of similar devices, potentially allowing a single device driver
> to match against several devices.
>
> The recommended format is "manufacturer,model", where manufacturer is a string describing the name
> of the manufacturer (such as a stock ticker symbol), and model specifies the model number.
>
> The compatible string should consist only of lowercase letters, digits and dashes, and should start with a letter.
> A single comma is typically only used following a vendor prefix. Underscores should not be used.
>
> Example:
> compatible = "fsl,mpc8641", "ns16550";
> In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a
> driver was not found, it would then try to locate a driver that supported the more general ns16550 device type.
I think I understand this for individual components,
but with a SoM or complete product I get confused.
Can I understand a SoM or product as a composite device,
such as a usb to uart + i2c + gpio + spi adapter?
> Let me answer with a question, because you neither answer mine nor
> provide detailed information.
>
> Is Cortex-A15 compatible with Cortex-A7 in the Devicetree? No.
Curious! Actually I don't fully understand why that would be.
Based on the definition above, I would agree that
neither cortex-a7 nor cortex-a17 are specializations of each other.
They just happen to both support armv7-a instruction set.
> Now what
> does it mean to your case?
>
> I don't even understand what is your case.
I see :(
Yes there is a disconnect *somewhere*.
I shall try again:
Marvell is selling two chips:
1. CN9130, High-Performance Multi-Core CPU, System on Chip
(can be used alone)
2. 88F8215, SouthBridge Communication Processor, System on Chip
(only usable in combination with a CN9130)
Now, in terms of compatible string, what happens when a board
has multiples of these?
> What is 9131 and 9132?
I have no idea who came up with 9131 and 9132.
But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com>
when he submitted cn9131-db.dts (Marvell evaluation board):
Extend the support of the CN9130 by adding an external CP115.
The last number indicates how many external CP115 are used.
>
>
>> From software perspective we can always down-grade,
>> i.e. run software only aware of the AP on 9130, 9131 or 9132.
>> But we can't run software referencing the external CPs
>> if they are not connected.
> Same with Cortex A15 and A7, right?
Right.
>
>
>>>>>> - const: marvell,armada-ap807-quad
>>>>>> - const: marvell,armada-ap807
>>>>> Anyway, 6 compatibles is beyond useful amount. What are you expressing
>>>>> here?
>>>> I copied this part from the examples earlier in the file, such as:
>>>> - description: Armada CN9132 SoC with two external CPs
>>>> items:
>>>> - const: marvell,cn9132
>>>> - const: marvell,cn9131
>>>> - const: marvell,cn9130
>>>> - const: marvell,armada-ap807-quad
>>>> - const: marvell,armada-ap807
>>>>> Why is this even armada ap807?
>>>> We noticed ap807 != ap806 (cn913x != 8040),
>>>> because the thermal sensor coefficients converting
>>>> raw values to celsius differed.
>>> That's also not the best example.Might be correct but also looks
>>> over-complicated. The point of board-level compatibles is to identify
>>> machine and its common parts. It has little impact inside of kernel (at
>>> least should be almost no users inside!)
>> Indeed, the temperature coefficients are handled by the thermal device
>> compatible string, not board-level.
>>> , but there can be some users,
>>> e.g. firmware or user-space.
>>>
>>> This claims that cn9132 is compatible with ap807, so you have exactly
>>> the same base. The same base is not CPU! It's about the S in SoC, so
>>> "System".
>> I would think since the base is always a single chip combining 1x AP+CP,
>> the "system" is marvell,cn9130.
>> For Armada 8040, the system would be marvell,armada8040 by same
>> logic (also combining 1x AP+CP, different version, not extensible).
>>> Could firmware use marvell,armada-ap807 compatible to properly
>>> detect type of system and treat all these boards as ap807?
>> I have not looked into presence detection for CP's during initialization.
>> U-Boot support without spaghetti is a future Me task.
> ???
>
>> I suspect it is possible with asterisk *, because so far I have only seen
>> configuration with at least 1 CP, never with 0.
>> Presence of a boot-rom on each die e.g. supports this idea.
> I still don't understand.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Dan Carpenter @ 2024-03-27 10:46 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, linux-arm-kernel, linux-kernel,
devicetree, linux-gpio, Peng Fan, Oleksii Moisieiev
In-Reply-To: <20240323-pinctrl-scmi-v6-3-a895243257c0@nxp.com>
Looks really nice. Just a few small comments below.
On Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) wrote:
> +
> +struct scmi_msg_func_set {
> + __le32 identifier;
> + __le32 function_id;
> + __le32 flags;
> +};
This scmi_msg_func_set struct is unused. Delete.
> +static void
> +iter_pinctrl_settings_get_prepare_message(void *message, u32 desc_index,
> + const void *priv)
> +{
> + struct scmi_msg_settings_get *msg = message;
> + const struct scmi_settings_get_ipriv *p = priv;
> + u32 attributes;
> +
> + attributes = FIELD_PREP(CONFIG_FLAG_MASK, p->flag) |
> + FIELD_PREP(SELECTOR_MASK, p->type);
> +
> + if (p->flag == 1)
> + attributes |= FIELD_PREP(SKIP_CONFIGS_MASK, desc_index);
> + else if (!p->flag)
This is a nit-pick but could you change these !p->flag conditions to
p->flag == 0? It's a number zero, not a bool.
> + attributes |= FIELD_PREP(CONFIG_TYPE_MASK, p->config_types[0]);
> +
> + msg->attributes = cpu_to_le32(attributes);
> + msg->identifier = cpu_to_le32(p->selector);
> +}
> +
> +static int
> +iter_pinctrl_settings_get_update_state(struct scmi_iterator_state *st,
> + const void *response, void *priv)
> +{
> + const struct scmi_resp_settings_get *r = response;
> + struct scmi_settings_get_ipriv *p = priv;
> +
> + if (p->flag == 1) {
> + st->num_returned = le32_get_bits(r->num_configs, GENMASK(7, 0));
> + st->num_remaining = le32_get_bits(r->num_configs,
> + GENMASK(31, 24));
> + } else {
> + st->num_returned = 1;
> + st->num_remaining = 0;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +iter_pinctrl_settings_get_process_response(const struct scmi_protocol_handle *ph,
> + const void *response,
> + struct scmi_iterator_state *st,
> + void *priv)
> +{
> + const struct scmi_resp_settings_get *r = response;
> + struct scmi_settings_get_ipriv *p = priv;
> +
> + if (!p->flag) {
if (p->flag == 0) {
> + if (p->config_types[0] !=
> + le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0)))
> + return -EINVAL;
> + } else if (p->flag == 1) {
> + p->config_types[st->desc_index + st->loop_idx] =
> + le32_get_bits(r->configs[st->loop_idx * 2],
> + GENMASK(7, 0));
> + } else if (p->flag == 2) {
> + return 0;
> + }
> +
> + p->config_values[st->desc_index + st->loop_idx] =
> + le32_to_cpu(r->configs[st->loop_idx * 2 + 1]);
> +
> + return 0;
> +}
> +
> +static int
> +scmi_pinctrl_settings_get(const struct scmi_protocol_handle *ph, u32 selector,
> + enum scmi_pinctrl_selector_type type,
> + enum scmi_pinctrl_conf_type config_type,
> + u32 *config_value)
> +{
> + int ret;
> + void *iter;
> + struct scmi_iterator_ops ops = {
> + .prepare_message = iter_pinctrl_settings_get_prepare_message,
> + .update_state = iter_pinctrl_settings_get_update_state,
> + .process_response = iter_pinctrl_settings_get_process_response,
> + };
> + struct scmi_settings_get_ipriv ipriv = {
> + .selector = selector,
> + .type = type,
> + .flag = 0,
->flag should be 0-2.
> + .config_types = &config_type,
> + .config_values = config_value,
> + };
> +
> + if (!config_value || type == FUNCTION_TYPE)
^^^^^^^^^^^^
config_value should be optional for flag == 2.
regards,
dan carpenter
> + return -EINVAL;
> +
> + ret = scmi_pinctrl_validate_id(ph, selector, type);
> + if (ret)
> + return ret;
> +
> + iter = ph->hops->iter_response_init(ph, &ops, 1, PINCTRL_SETTINGS_GET,
> + sizeof(struct scmi_msg_settings_get),
> + &ipriv);
> +
> + if (IS_ERR(iter))
> + return PTR_ERR(iter);
> +
> + return ph->hops->iter_response_run(iter);
> +}
> +
^ permalink raw reply
* [PATCH v6 3/3] mtd: rawnand: Add Loongson-1 NAND Controller driver
From: Keguang Zhang via B4 Relay @ 2024-03-27 10:44 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-mtd, linux-kernel, linux-mips, devicetree, Keguang Zhang
In-Reply-To: <20240327-loongson1-nand-v6-0-7f9311cef020@gmail.com>
From: Keguang Zhang <keguang.zhang@gmail.com>
This patch adds NAND Controller driver for Loongson-1 SoCs.
Signed-off-by: Keguang Zhang <keguang.zhang@gmail.com>
---
Changes in v6:
- Amend Kconfig
- Add DT support
- Use DT data instead of platform data
- Remove MAX_ID_SIZE
- Remove case NAND_OP_CMD_INSTR in ls1x_nand_set_controller()
- Move ECC configuration to ls1x_nand_attach_chip()
- Rename variable "nand" to "ls1x"
- Rename variable "nc" to "nfc"
- Some minor fixes
- Link to v5: https://lore.kernel.org/all/20210520224213.7907-1-keguang.zhang@gmail.com
Changes in v5:
- Update the driver to fit the raw NAND framework.
- Implement exec_op() instead of legacy cmdfunc().
- Use dma_request_chan() instead of dma_request_channel().
- Some minor fixes and cleanups.
Changes in v4:
- Retrieve the controller from nand_hw_control.
Changes in v3:
- Replace __raw_readl/__raw_writel with readl/writel.
- Split ls1x_nand into two structures:
ls1x_nand_chip and ls1x_nand_controller.
Changes in v2:
- Modify the dependency in Kconfig due to the changes of DMA module.
---
drivers/mtd/nand/raw/Kconfig | 7 +
drivers/mtd/nand/raw/Makefile | 1 +
drivers/mtd/nand/raw/loongson1_nand.c | 748 ++++++++++++++++++++++++++++++++++
3 files changed, 756 insertions(+)
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index cbf8ae85e1ae..9e34ce05341b 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -449,6 +449,13 @@ config MTD_NAND_RENESAS
Enables support for the NAND controller found on Renesas R-Car
Gen3 and RZ/N1 SoC families.
+config MTD_NAND_LOONGSON1
+ tristate "Loongson1 NAND controller"
+ depends on LOONGSON1_DMA || COMPILE_TEST
+ select REGMAP_MMIO
+ help
+ Enables support for NAND controller on Loongson1 SoCs.
+
comment "Misc"
config MTD_SM_COMMON
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index 25120a4afada..b3c65cab819c 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_MTD_NAND_INTEL_LGM) += intel-nand-controller.o
obj-$(CONFIG_MTD_NAND_ROCKCHIP) += rockchip-nand-controller.o
obj-$(CONFIG_MTD_NAND_PL35X) += pl35x-nand-controller.o
obj-$(CONFIG_MTD_NAND_RENESAS) += renesas-nand-controller.o
+obj-$(CONFIG_MTD_NAND_LOONGSON1) += loongson1_nand.o
nand-objs := nand_base.o nand_legacy.o nand_bbt.o nand_timings.o nand_ids.o
nand-objs += nand_onfi.o
diff --git a/drivers/mtd/nand/raw/loongson1_nand.c b/drivers/mtd/nand/raw/loongson1_nand.c
new file mode 100644
index 000000000000..d0f66a81ba0b
--- /dev/null
+++ b/drivers/mtd/nand/raw/loongson1_nand.c
@@ -0,0 +1,748 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * NAND Controller Driver for Loongson-1 SoC
+ *
+ * Copyright (C) 2015-2024 Keguang Zhang <keguang.zhang@gmail.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/dmaengine.h>
+#include <linux/dma-mapping.h>
+#include <linux/iopoll.h>
+#include <linux/mtd/mtd.h>
+#include <linux/mtd/rawnand.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/sizes.h>
+
+/* Loongson-1 NAND Controller Registers */
+#define NAND_CMD 0x0
+#define NAND_ADDR1 0x4
+#define NAND_ADDR2 0x8
+#define NAND_TIMING 0xc
+#define NAND_IDL 0x10
+#define NAND_IDH_STATUS 0x14
+#define NAND_PARAM 0x18
+#define NAND_OP_NUM 0x1c
+#define MAX_DUMP_REGS 0x20
+
+#define NAND_DMA_ADDR 0x40
+
+/* NAND Command Register Bits */
+#define OP_DONE BIT(10)
+#define OP_SPARE BIT(9)
+#define OP_MAIN BIT(8)
+#define CMD_STATUS BIT(7)
+#define CMD_RESET BIT(6)
+#define CMD_READID BIT(5)
+#define BLOCKS_ERASE BIT(4)
+#define CMD_ERASE BIT(3)
+#define CMD_WRITE BIT(2)
+#define CMD_READ BIT(1)
+#define CMD_VALID BIT(0)
+
+#define MAX_ADDR_CYC 5U
+
+#define WAIT_CYCLE_MASK GENMASK(7, 0)
+#define HOLD_CYCLE_MASK GENMASK(15, 8)
+#define CELL_SIZE_MASK GENMASK(11, 8)
+
+#define BITS_PER_WORD (4 * BITS_PER_BYTE)
+
+/* macros for registers read/write */
+#define nand_readl(nfc, off) \
+ readl((nfc)->reg_base + (off))
+
+#define nand_writel(nfc, off, val) \
+ writel((val), (nfc)->reg_base + (off))
+
+struct ls1x_nfc_data {
+ unsigned int status_field;
+ unsigned int op_scope_field;
+ unsigned int hold_cycle;
+ unsigned int wait_cycle;
+ void (*parse_address)(struct nand_chip *chip, const u8 *addrs,
+ unsigned int naddrs, int cmd);
+};
+
+struct ls1x_nfc {
+ void __iomem *reg_base;
+ struct regmap *regmap;
+ const struct ls1x_nfc_data *data;
+ __le32 addr1_reg;
+ __le32 addr2_reg;
+
+ char *buf;
+ unsigned int len;
+ unsigned int rdy_timeout;
+
+ /* DMA Engine stuff */
+ struct dma_chan *dma_chan;
+ dma_cookie_t dma_cookie;
+ struct completion dma_complete;
+};
+
+struct ls1x_nand {
+ struct device *dev;
+ struct nand_chip chip;
+ struct nand_controller controller;
+ struct ls1x_nfc nfc;
+};
+
+static const struct regmap_config ls1x_nand_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static inline void ls1b_nand_parse_address(struct nand_chip *chip,
+ const u8 *addrs,
+ unsigned int naddrs, int cmd)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ unsigned int page_shift = chip->page_shift + 1;
+ int i;
+
+ nfc->addr1_reg = 0;
+ nfc->addr2_reg = 0;
+
+ if (cmd == CMD_ERASE) {
+ page_shift = chip->page_shift;
+
+ for (i = 0; i < min(MAX_ADDR_CYC - 2, naddrs); i++)
+ nfc->addr1_reg |=
+ (u32)addrs[i] << (page_shift + BITS_PER_BYTE * i);
+ if (i == MAX_ADDR_CYC - 2)
+ nfc->addr2_reg |=
+ (u32)addrs[i] >> (BITS_PER_WORD - page_shift -
+ BITS_PER_BYTE * (i - 1));
+
+ return;
+ }
+
+ for (i = 0; i < min(2U, naddrs); i++)
+ nfc->addr1_reg |= (u32)addrs[i] << BITS_PER_BYTE * i;
+ for (i = 2; i < min(MAX_ADDR_CYC, naddrs); i++)
+ nfc->addr1_reg |=
+ (u32)addrs[i] << (page_shift + BITS_PER_BYTE * (i - 2));
+ if (i == MAX_ADDR_CYC)
+ nfc->addr2_reg |=
+ (u32)addrs[i] >> (BITS_PER_WORD - page_shift -
+ BITS_PER_BYTE * (i - 1));
+}
+
+static inline void ls1c_nand_parse_address(struct nand_chip *chip,
+ const u8 *addrs,
+ unsigned int naddrs, int cmd)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ int i;
+
+ nfc->addr1_reg = 0;
+ nfc->addr2_reg = 0;
+
+ if (cmd == CMD_ERASE) {
+ for (i = 0; i < min(MAX_ADDR_CYC, naddrs); i++)
+ nfc->addr2_reg |= (u32)addrs[i] << BITS_PER_BYTE * i;
+
+ return;
+ }
+
+ for (i = 0; i < min(MAX_ADDR_CYC, naddrs); i++) {
+ if (i < 2)
+ nfc->addr1_reg |= (u32)addrs[i] << BITS_PER_BYTE * i;
+ else
+ nfc->addr2_reg |=
+ (u32)addrs[i] << BITS_PER_BYTE * (i - 2);
+ }
+}
+
+static int ls1x_nand_set_controller(struct nand_chip *chip,
+ const struct nand_subop *subop, int cmd)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ unsigned int op_id;
+
+ nfc->buf = NULL;
+ nfc->len = 0;
+ nfc->rdy_timeout = 0;
+
+ for (op_id = 0; op_id < subop->ninstrs; op_id++) {
+ const struct nand_op_instr *instr = &subop->instrs[op_id];
+ unsigned int offset, naddrs;
+ const u8 *addrs;
+
+ switch (instr->type) {
+ case NAND_OP_ADDR_INSTR:
+ offset = nand_subop_get_addr_start_off(subop, op_id);
+ naddrs = nand_subop_get_num_addr_cyc(subop, op_id);
+ addrs = &instr->ctx.addr.addrs[offset];
+
+ nfc->data->parse_address(chip, addrs, naddrs, cmd);
+ /* set NAND address */
+ nand_writel(nfc, NAND_ADDR1, nfc->addr1_reg);
+ nand_writel(nfc, NAND_ADDR2, nfc->addr2_reg);
+ break;
+ case NAND_OP_DATA_IN_INSTR:
+ case NAND_OP_DATA_OUT_INSTR:
+ offset = nand_subop_get_data_start_off(subop, op_id);
+ nfc->len = nand_subop_get_data_len(subop, op_id);
+ if (instr->type == NAND_OP_DATA_IN_INSTR)
+ nfc->buf =
+ (void *)instr->ctx.data.buf.in + offset;
+ else if (instr->type == NAND_OP_DATA_OUT_INSTR)
+ nfc->buf =
+ (void *)instr->ctx.data.buf.out + offset;
+
+ if (cmd & (CMD_READID | CMD_STATUS))
+ break;
+
+ if (!IS_ALIGNED((u32)nfc->buf, chip->buf_align)) {
+ dev_err(ls1x->dev,
+ "nfc->buf %px is not aligned!\n",
+ nfc->buf);
+ return -EOPNOTSUPP;
+ } else if (!IS_ALIGNED(nfc->len, chip->buf_align)) {
+ dev_err(ls1x->dev,
+ "nfc->len %u is not aligned!\n",
+ nfc->len);
+ return -EOPNOTSUPP;
+ }
+
+ /* set NAND data length */
+ nand_writel(nfc, NAND_OP_NUM, nfc->len);
+
+ if (nfc->data->op_scope_field) {
+ int op_scope = nfc->len << ffs(nfc->data->op_scope_field);
+
+ regmap_update_bits(nfc->regmap, NAND_PARAM,
+ nfc->data->op_scope_field,
+ op_scope);
+ }
+
+ break;
+ case NAND_OP_WAITRDY_INSTR:
+ nfc->rdy_timeout = instr->ctx.waitrdy.timeout_ms;
+ break;
+ default:
+ break;
+ }
+ }
+
+ /* set NAND erase block count */
+ if (cmd & CMD_ERASE)
+ nand_writel(nfc, NAND_OP_NUM, 1);
+ /* set NAND operation region */
+ if (nfc->buf && nfc->len)
+ cmd |= OP_SPARE | OP_MAIN;
+
+ /* set NAND command */
+ nand_writel(nfc, NAND_CMD, cmd);
+ /* Trigger operation */
+ regmap_write_bits(nfc->regmap, NAND_CMD, CMD_VALID, CMD_VALID);
+
+ return 0;
+}
+
+static void ls1x_nand_dma_callback(void *data)
+{
+ struct ls1x_nand *ls1x = (struct ls1x_nand *)data;
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ enum dma_status status;
+
+ status = dmaengine_tx_status(nfc->dma_chan, nfc->dma_cookie, NULL);
+ if (likely(status == DMA_COMPLETE))
+ dev_dbg(ls1x->dev, "DMA complete with cookie=%d\n",
+ nfc->dma_cookie);
+ else
+ dev_err(ls1x->dev, "DMA error with cookie=%d\n",
+ nfc->dma_cookie);
+
+ complete(&nfc->dma_complete);
+}
+
+static int ls1x_nand_dma_transfer(struct ls1x_nand *ls1x, bool is_write)
+{
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ struct dma_chan *chan = nfc->dma_chan;
+ struct dma_async_tx_descriptor *desc;
+ enum dma_data_direction data_dir =
+ is_write ? DMA_TO_DEVICE : DMA_FROM_DEVICE;
+ enum dma_transfer_direction xfer_dir =
+ is_write ? DMA_MEM_TO_DEV : DMA_DEV_TO_MEM;
+ dma_addr_t dma_addr;
+ int ret;
+
+ dma_addr = dma_map_single(chan->device->dev, nfc->buf, nfc->len,
+ data_dir);
+ if (dma_mapping_error(chan->device->dev, dma_addr)) {
+ dev_err(ls1x->dev, "failed to map DMA buffer!\n");
+ return -ENXIO;
+ }
+
+ desc = dmaengine_prep_slave_single(chan, dma_addr, nfc->len, xfer_dir,
+ DMA_PREP_INTERRUPT);
+ if (!desc) {
+ dev_err(ls1x->dev, "failed to prepare DMA descriptor!\n");
+ ret = PTR_ERR(desc);
+ goto err;
+ }
+ desc->callback = ls1x_nand_dma_callback;
+ desc->callback_param = ls1x;
+
+ nfc->dma_cookie = dmaengine_submit(desc);
+ ret = dma_submit_error(nfc->dma_cookie);
+ if (ret) {
+ dev_err(ls1x->dev, "failed to submit DMA descriptor!\n");
+ goto err;
+ }
+
+ dev_dbg(ls1x->dev, "issue DMA with cookie=%d\n", nfc->dma_cookie);
+ dma_async_issue_pending(chan);
+
+ ret = wait_for_completion_timeout(&nfc->dma_complete,
+ msecs_to_jiffies(nfc->rdy_timeout));
+ if (ret <= 0) {
+ dev_err(ls1x->dev, "DMA timeout!%u\n", nfc->rdy_timeout);
+ dmaengine_terminate_all(chan);
+ ret = -EIO;
+ }
+ ret = 0;
+err:
+ dma_unmap_single(chan->device->dev, dma_addr, nfc->len, data_dir);
+
+ return ret;
+}
+
+static inline int ls1x_nand_wait_for_op_done(struct ls1x_nfc *nfc)
+{
+ unsigned int val;
+ int ret = 0;
+
+ /* Wait for operation done */
+ if (nfc->rdy_timeout)
+ ret = regmap_read_poll_timeout(nfc->regmap, NAND_CMD, val,
+ val & OP_DONE, 0,
+ nfc->rdy_timeout * 1000);
+
+ return ret;
+}
+
+static int ls1x_nand_reset_exec(struct nand_chip *chip,
+ const struct nand_subop *subop)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ int ret;
+
+ ls1x_nand_set_controller(chip, subop, CMD_RESET);
+
+ ret = ls1x_nand_wait_for_op_done(nfc);
+ if (ret)
+ dev_err(ls1x->dev, "CMD_RESET failed! %d\n", ret);
+
+ return ret;
+}
+
+static int ls1x_nand_read_id_exec(struct nand_chip *chip,
+ const struct nand_subop *subop)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ long long idl = 0;
+ int i, ret;
+
+ ls1x_nand_set_controller(chip, subop, CMD_READID);
+
+ ret = ls1x_nand_wait_for_op_done(nfc);
+ if (ret) {
+ dev_err(ls1x->dev, "CMD_READID failed! %d\n", ret);
+ print_hex_dump_debug("REG: ", DUMP_PREFIX_OFFSET, 16, 4,
+ nfc->reg_base, MAX_DUMP_REGS, false);
+ return ret;
+ }
+
+ idl = __be32_to_cpu(nand_readl(nfc, NAND_IDL));
+ memset(nfc->buf, 0x0, nfc->len);
+
+ for (i = 0; i < nfc->len; i++) {
+ if (i > 0)
+ nfc->buf[i] = (char)(idl >> (i - 1) * BITS_PER_BYTE);
+ else
+ nfc->buf[i] = (char)nand_readl(nfc, NAND_IDH_STATUS);
+ }
+
+ return ret;
+}
+
+static int ls1x_nand_erase_exec(struct nand_chip *chip,
+ const struct nand_subop *subop)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ int ret;
+
+ ls1x_nand_set_controller(chip, subop, CMD_ERASE);
+
+ ret = ls1x_nand_wait_for_op_done(nfc);
+ if (ret) {
+ dev_err(ls1x->dev, "CMD_ERASE failed! %d\n", ret);
+ print_hex_dump_debug("REG: ", DUMP_PREFIX_OFFSET, 16, 4,
+ nfc->reg_base, MAX_DUMP_REGS, false);
+ }
+
+ return ret;
+}
+
+static int ls1x_nand_read_exec(struct nand_chip *chip,
+ const struct nand_subop *subop)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ bool is_write = false;
+ int ret;
+
+ ls1x_nand_set_controller(chip, subop, CMD_READ);
+
+ ret = ls1x_nand_dma_transfer(ls1x, is_write);
+ if (ret)
+ return ret;
+
+ ret = ls1x_nand_wait_for_op_done(nfc);
+ if (ret) {
+ dev_err(ls1x->dev, "CMD_READ failed! %d\n", ret);
+ print_hex_dump_debug("REG: ", DUMP_PREFIX_OFFSET, 16, 4,
+ nfc->reg_base, MAX_DUMP_REGS, false);
+ }
+
+ return ret;
+}
+
+static int ls1x_nand_write_exec(struct nand_chip *chip,
+ const struct nand_subop *subop)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ bool is_write = true;
+ int ret;
+
+ ls1x_nand_set_controller(chip, subop, CMD_WRITE);
+
+ ret = ls1x_nand_dma_transfer(ls1x, is_write);
+ if (ret)
+ return ret;
+
+ ret = ls1x_nand_wait_for_op_done(nfc);
+ if (ret) {
+ dev_err(ls1x->dev, "CMD_WRITE failed! %d\n", ret);
+ print_hex_dump_debug("REG: ", DUMP_PREFIX_OFFSET, 16, 4,
+ nfc->reg_base, MAX_DUMP_REGS, false);
+ }
+
+ return ret;
+}
+
+static int ls1x_nand_read_status_exec(struct nand_chip *chip,
+ const struct nand_subop *subop)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ int val, ret;
+
+ ls1x_nand_set_controller(chip, subop, CMD_STATUS);
+
+ ret = ls1x_nand_wait_for_op_done(nfc);
+ if (ret) {
+ dev_err(ls1x->dev, "CMD_STATUS failed! %d\n", ret);
+ return ret;
+ }
+
+ val = nand_readl(nfc, NAND_IDH_STATUS) & ~nfc->data->status_field;
+ nfc->buf[0] = val << ffs(nfc->data->status_field);
+
+ return ret;
+}
+
+static const struct nand_op_parser ls1x_nand_op_parser = NAND_OP_PARSER(
+ NAND_OP_PARSER_PATTERN(
+ ls1x_nand_reset_exec,
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_WAITRDY_ELEM(false)),
+ NAND_OP_PARSER_PATTERN(
+ ls1x_nand_read_id_exec,
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDR_CYC),
+ NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 8)),
+ NAND_OP_PARSER_PATTERN(
+ ls1x_nand_erase_exec,
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDR_CYC),
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_WAITRDY_ELEM(false)),
+ NAND_OP_PARSER_PATTERN(
+ ls1x_nand_read_exec,
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDR_CYC),
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_WAITRDY_ELEM(true),
+ NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 0)),
+ NAND_OP_PARSER_PATTERN(
+ ls1x_nand_write_exec,
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_ADDR_ELEM(false, MAX_ADDR_CYC),
+ NAND_OP_PARSER_PAT_DATA_OUT_ELEM(false, 0),
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_WAITRDY_ELEM(true)),
+ NAND_OP_PARSER_PATTERN(
+ ls1x_nand_read_status_exec,
+ NAND_OP_PARSER_PAT_CMD_ELEM(false),
+ NAND_OP_PARSER_PAT_DATA_IN_ELEM(false, 1)),
+ );
+
+static int ls1x_nand_exec_op(struct nand_chip *chip,
+ const struct nand_operation *op, bool check_only)
+{
+ return nand_op_parser_exec_op(chip, &ls1x_nand_op_parser, op,
+ check_only);
+}
+
+static int ls1x_nand_attach_chip(struct nand_chip *chip)
+{
+ struct ls1x_nand *ls1x = nand_get_controller_data(chip);
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ u64 chipsize = nanddev_target_size(&chip->base);
+ int cell_size = 0;
+
+ switch (chipsize) {
+ case SZ_128M:
+ cell_size = 0x0;
+ break;
+ case SZ_256M:
+ cell_size = 0x1;
+ break;
+ case SZ_512M:
+ cell_size = 0x2;
+ break;
+ case SZ_1G:
+ cell_size = 0x3;
+ break;
+ case SZ_2G:
+ cell_size = 0x4;
+ break;
+ case SZ_4G:
+ cell_size = 0x5;
+ break;
+ case (SZ_2G * SZ_4G): /* 8G */
+ cell_size = 0x6;
+ break;
+ case (SZ_4G * SZ_4G): /* 16G */
+ cell_size = 0x7;
+ break;
+ default:
+ dev_err(ls1x->dev, "unsupported chip size: %llu MB\n",
+ chipsize);
+ break;
+ }
+
+ /* Set cell size */
+ regmap_update_bits(nfc->regmap, NAND_PARAM, CELL_SIZE_MASK,
+ FIELD_PREP(CELL_SIZE_MASK, cell_size));
+
+ regmap_update_bits(nfc->regmap, NAND_TIMING, HOLD_CYCLE_MASK,
+ FIELD_PREP(HOLD_CYCLE_MASK, nfc->data->hold_cycle));
+ regmap_update_bits(nfc->regmap, NAND_TIMING, WAIT_CYCLE_MASK,
+ FIELD_PREP(WAIT_CYCLE_MASK, nfc->data->wait_cycle));
+
+ chip->ecc.read_page_raw = nand_monolithic_read_page_raw;
+ chip->ecc.write_page_raw = nand_monolithic_write_page_raw;
+ chip->options |= NAND_MONOLITHIC_READ;
+
+ return 0;
+}
+
+static const struct nand_controller_ops ls1x_nfc_ops = {
+ .exec_op = ls1x_nand_exec_op,
+ .attach_chip = ls1x_nand_attach_chip,
+};
+
+static void ls1x_nand_controller_cleanup(struct ls1x_nand *ls1x)
+{
+ if (ls1x->nfc.dma_chan)
+ dma_release_channel(ls1x->nfc.dma_chan);
+}
+
+static int ls1x_nand_controller_init(struct ls1x_nand *ls1x,
+ struct platform_device *pdev)
+{
+ struct ls1x_nfc *nfc = &ls1x->nfc;
+ struct dma_slave_config cfg;
+ int ret;
+
+ nfc->reg_base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(nfc->reg_base))
+ return PTR_ERR(nfc->reg_base);
+
+ nfc->regmap = devm_regmap_init_mmio(ls1x->dev, nfc->reg_base,
+ &ls1x_nand_regmap_config);
+ if (IS_ERR(nfc->regmap))
+ return dev_err_probe(ls1x->dev, PTR_ERR(nfc->regmap),
+ "failed to init regmap\n");
+
+ nfc->dma_chan = dma_request_chan(ls1x->dev, "rxtx");
+ if (IS_ERR(nfc->dma_chan))
+ return dev_err_probe(ls1x->dev, PTR_ERR(nfc->dma_chan),
+ "failed to request DMA channel\n");
+ dev_info(ls1x->dev, "got %s for %s access\n",
+ dma_chan_name(nfc->dma_chan), dev_name(ls1x->dev));
+
+ cfg.src_addr = CPHYSADDR(nfc->reg_base + NAND_DMA_ADDR);
+ cfg.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+ cfg.dst_addr = CPHYSADDR(nfc->reg_base + NAND_DMA_ADDR);
+ cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+
+ ret = dmaengine_slave_config(nfc->dma_chan, &cfg);
+ if (ret) {
+ dev_err(ls1x->dev, "failed to config DMA channel\n");
+ dma_release_channel(nfc->dma_chan);
+ return ret;
+ }
+
+ init_completion(&nfc->dma_complete);
+
+ return 0;
+}
+
+static int ls1x_nand_chip_init(struct ls1x_nand *ls1x)
+{
+ int nchips = of_get_child_count(ls1x->dev->of_node);
+ struct device_node *chip_np;
+ struct nand_chip *chip = &ls1x->chip;
+ struct mtd_info *mtd = nand_to_mtd(chip);
+ int ret = 0;
+
+ if (nchips != 1)
+ return dev_err_probe(ls1x->dev, -EINVAL,
+ "Currently one NAND chip supported\n");
+
+ chip_np = of_get_next_child(ls1x->dev->of_node, NULL);
+ if (!chip_np)
+ return dev_err_probe(ls1x->dev, -ENODEV,
+ "failed to get child node for NAND chip\n");
+
+ chip->controller = &ls1x->controller;
+ chip->options = NAND_NO_SUBPAGE_WRITE | NAND_USES_DMA | NAND_BROKEN_XD;
+ chip->buf_align = 4;
+ nand_set_controller_data(chip, ls1x);
+ nand_set_flash_node(chip, chip_np);
+
+ mtd->dev.parent = ls1x->dev;
+ mtd->name = "ls1x-nand";
+ mtd->owner = THIS_MODULE;
+
+ ret = nand_scan(chip, 1);
+ if (ret) {
+ of_node_put(chip_np);
+ return ret;
+ }
+
+ ret = mtd_device_register(mtd, NULL, 0);
+ if (ret) {
+ dev_err(ls1x->dev, "failed to register MTD device! %d\n", ret);
+ nand_cleanup(chip);
+ of_node_put(chip_np);
+ }
+
+ return ret;
+}
+
+static int ls1x_nand_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ const struct ls1x_nfc_data *data;
+ struct ls1x_nand *ls1x;
+ int ret;
+
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data)
+ return -ENODEV;
+
+ ls1x = devm_kzalloc(dev, sizeof(*ls1x), GFP_KERNEL);
+ if (!ls1x)
+ return -ENOMEM;
+
+ ls1x->nfc.data = data;
+ ls1x->dev = dev;
+ ls1x->controller.ops = &ls1x_nfc_ops;
+ nand_controller_init(&ls1x->controller);
+
+ ret = ls1x_nand_controller_init(ls1x, pdev);
+ if (ret)
+ return ret;
+
+ ret = ls1x_nand_chip_init(ls1x);
+ if (ret)
+ goto err;
+
+ platform_set_drvdata(pdev, ls1x);
+
+ return 0;
+err:
+ ls1x_nand_controller_cleanup(ls1x);
+ return ret;
+}
+
+static int ls1x_nand_remove(struct platform_device *pdev)
+{
+ struct ls1x_nand *ls1x = platform_get_drvdata(pdev);
+ struct nand_chip *chip = &ls1x->chip;
+ int ret;
+
+ ret = mtd_device_unregister(nand_to_mtd(chip));
+ WARN_ON(ret);
+ nand_cleanup(chip);
+ ls1x_nand_controller_cleanup(ls1x);
+
+ return 0;
+}
+
+static const struct ls1x_nfc_data ls1b_nfc_data = {
+ .status_field = GENMASK(15, 8),
+ .hold_cycle = 0x2,
+ .wait_cycle = 0xc,
+ .parse_address = ls1b_nand_parse_address,
+};
+
+static const struct ls1x_nfc_data ls1c_nfc_data = {
+ .status_field = GENMASK(23, 16),
+ .op_scope_field = GENMASK(29, 16),
+ .hold_cycle = 0x2,
+ .wait_cycle = 0xc,
+ .parse_address = ls1c_nand_parse_address,
+};
+
+static const struct of_device_id ls1x_nfc_match[] = {
+ { .compatible = "loongson,ls1b-nfc", .data = &ls1b_nfc_data },
+ { .compatible = "loongson,ls1c-nfc", .data = &ls1c_nfc_data },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, ls1x_nfc_match);
+
+static struct platform_driver ls1x_nand_driver = {
+ .probe = ls1x_nand_probe,
+ .remove = ls1x_nand_remove,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = ls1x_nfc_match,
+ },
+};
+
+module_platform_driver(ls1x_nand_driver);
+
+MODULE_AUTHOR("Keguang Zhang <keguang.zhang@gmail.com>");
+MODULE_DESCRIPTION("Loongson-1 NAND Controller driver");
+MODULE_LICENSE("GPL");
--
2.40.1
^ permalink raw reply related
* [PATCH v6 2/3] mtd: rawnand: Enable monolithic read when reading subpages
From: Keguang Zhang via B4 Relay @ 2024-03-27 10:44 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-mtd, linux-kernel, linux-mips, devicetree, Keguang Zhang
In-Reply-To: <20240327-loongson1-nand-v6-0-7f9311cef020@gmail.com>
From: Keguang Zhang <keguang.zhang@gmail.com>
nand_read_subpage() reads data and ECC data by two separate
operations.
This patch allows the NAND controllers who support
monolithic page read to do subpage read by a single operation,
which is more effective than nand_read_subpage().
---
Changes in v6:
- A newly added patch
Signed-off-by: Keguang Zhang <keguang.zhang@gmail.com>
---
drivers/mtd/nand/raw/nand_base.c | 5 +++--
include/linux/mtd/rawnand.h | 5 +++++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index d7dbbd469b89..eeb654c6b4fc 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -3630,7 +3630,7 @@ static int nand_do_read_ops(struct nand_chip *chip, loff_t from,
oob_required,
page);
else if (!aligned && NAND_HAS_SUBPAGE_READ(chip) &&
- !oob)
+ !NAND_HAS_MONOLITHIC_READ(chip) && !oob)
ret = chip->ecc.read_subpage(chip, col, bytes,
bufpoi, page);
else
@@ -3648,7 +3648,8 @@ static int nand_do_read_ops(struct nand_chip *chip, loff_t from,
* partial pages or when a bounce buffer is required.
*/
if (use_bounce_buf) {
- if (!NAND_HAS_SUBPAGE_READ(chip) && !oob &&
+ if ((!NAND_HAS_SUBPAGE_READ(chip) ||
+ NAND_HAS_MONOLITHIC_READ(chip)) && !oob &&
!(mtd->ecc_stats.failed - ecc_stats.failed) &&
(ops->mode != MTD_OPS_RAW)) {
chip->pagecache.page = realpage;
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index e84522e31301..92d3ab491c9c 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -150,6 +150,11 @@ struct gpio_desc;
/* Device needs 3rd row address cycle */
#define NAND_ROW_ADDR_3 BIT(14)
+/* Device supports monolithic reads */
+#define NAND_MONOLITHIC_READ BIT(15)
+/* Macros to identify the above */
+#define NAND_HAS_MONOLITHIC_READ(chip) ((chip->options & NAND_MONOLITHIC_READ))
+
/* Non chip related options */
/* This option skips the bbt scan during initialization. */
#define NAND_SKIP_BBTSCAN BIT(16)
--
2.40.1
^ permalink raw reply related
* [PATCH v6 1/3] dt-bindings: mtd: Add Loongson-1 NAND Controller
From: Keguang Zhang via B4 Relay @ 2024-03-27 10:43 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-mtd, linux-kernel, linux-mips, devicetree, Keguang Zhang
In-Reply-To: <20240327-loongson1-nand-v6-0-7f9311cef020@gmail.com>
From: Keguang Zhang <keguang.zhang@gmail.com>
Add devicetree binding document for Loongson-1 NAND Controller.
Signed-off-by: Keguang Zhang <keguang.zhang@gmail.com>
---
Changes in v6:
- A newly added patch
---
.../devicetree/bindings/mtd/loongson,ls1x-nfc.yaml | 66 ++++++++++++++++++++++
1 file changed, 66 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/loongson,ls1x-nfc.yaml b/Documentation/devicetree/bindings/mtd/loongson,ls1x-nfc.yaml
new file mode 100644
index 000000000000..2494c7b3b506
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/loongson,ls1x-nfc.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/loongson,ls1x-nfc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson-1 NAND Controller
+
+maintainers:
+ - Keguang Zhang <keguang.zhang@gmail.com>
+
+allOf:
+ - $ref: nand-controller.yaml
+
+properties:
+ compatible:
+ oneOf:
+ - const: loongson,ls1b-nfc
+ - items:
+ - enum:
+ - loongson,ls1a-nfc
+ - loongson,ls1c-nfc
+ - const: loongson,ls1b-nfc
+
+ reg:
+ maxItems: 1
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rxtx
+
+patternProperties:
+ "^nand@[0-3]$":
+ type: object
+ $ref: raw-nand-chip.yaml
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - dmas
+ - dma-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ nand-controller@1fe78000 {
+ compatible = "loongson,ls1b-nfc";
+ reg = <0x1fe78000 0x40>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dmas = <&dma 0>;
+ dma-names = "rxtx";
+
+ nand@0 {
+ reg = <0>;
+ nand-use-soft-ecc-engine;
+ nand-ecc-algo = "hamming";
+ };
+ };
--
2.40.1
^ permalink raw reply related
* [PATCH v6 0/3] Add support for Loongson-1 NAND
From: Keguang Zhang via B4 Relay @ 2024-03-27 10:43 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-mtd, linux-kernel, linux-mips, devicetree, Keguang Zhang
Add the driver and dt-binding document for Loongson-1 NAND.
And modify nand_read_subpage() to allow subpage read by a single operation.
Changes in v6:
- Amend Kconfig
- Add the dt-binding document
- Modify nand_read_subpage() to allow subpage read by a single operation
- Add DT support for driver
- Use DT data instead of platform data
- Remove MAX_ID_SIZE
- Remove case NAND_OP_CMD_INSTR in ls1x_nand_set_controller()
- Move ECC configuration to ls1x_nand_attach_chip()
- Rename variable "nand" to "ls1x"
- Rename variable "nc" to "nfc"
- Some minor fixes
- Link to v5: https://lore.kernel.org/all/20210520224213.7907-1-keguang.zhang@gmail.com
Changes in v5:
- Update the driver to fit the raw NAND framework.
- Implement exec_op() instead of legacy cmdfunc().
- Use dma_request_chan() instead of dma_request_channel().
- Some minor fixes and cleanups.
Changes in v4:
- Retrieve the controller from nand_hw_control.
Changes in v3:
- Replace __raw_readl/__raw_writel with readl/writel.
- Split ls1x_nand into two structures:
ls1x_nand_chip and ls1x_nand_controller.
Changes in v2:
- Modify the dependency in Kconfig due to the changes of DMA module.
Signed-off-by: Keguang Zhang <keguang.zhang@gmail.com>
---
Keguang Zhang (3):
dt-bindings: mtd: Add Loongson-1 NAND Controller
mtd: rawnand: Enable monolithic read when reading subpages
mtd: rawnand: Add Loongson-1 NAND Controller driver
.../devicetree/bindings/mtd/loongson,ls1x-nfc.yaml | 66 ++
drivers/mtd/nand/raw/Kconfig | 7 +
drivers/mtd/nand/raw/Makefile | 1 +
drivers/mtd/nand/raw/loongson1_nand.c | 748 +++++++++++++++++++++
drivers/mtd/nand/raw/nand_base.c | 5 +-
include/linux/mtd/rawnand.h | 5 +
6 files changed, 830 insertions(+), 2 deletions(-)
---
base-commit: 084c8e315db34b59d38d06e684b1a0dd07d30287
change-id: 20240316-loongson1-nand-98327d77e0f6
Best regards,
--
Keguang Zhang <keguang.zhang@gmail.com>
^ permalink raw reply
* Re: [PATCH RESEND v6 0/5] spmi: pmic-arb: Add support for multiple buses
From: Krzysztof Kozlowski @ 2024-03-27 10:44 UTC (permalink / raw)
To: Abel Vesa
Cc: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Srini Kandagatla,
Johan Hovold, linux-kernel, linux-arm-kernel, linux-arm-msm,
linux-mediatek, devicetree
In-Reply-To: <ZgP209t7IhdhcZIr@linaro.org>
On 27/03/2024 11:37, Abel Vesa wrote:
> On 24-03-27 10:23:51, Krzysztof Kozlowski wrote:
>> On 26/03/2024 17:28, Abel Vesa wrote:
>>> This RFC prepares for and adds support for 2 buses, which is supported
>>> in HW starting with version 7. Until now, none of the currently
>>> supported platforms in upstream have used the second bus. The X1E80100
>>> platform, on the other hand, needs the second bus for the USB2.0 to work
>>> as there are 3 SMB2360 PMICs which provide eUSB2 repeaters and they are
>>> all found on the second bus.
>>>
>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>>> ---
>>> Changes in v6:
>>> - Changed the compatible to platform specific (X1E80100) along with the
>>> schema. Fixed the spmi buses unit addresses and added the empty ranges
>>
>> Why resending after few days? And why without reviews?
>>
>
> If you are referring to the initial v6 patchset, it was sent more than a
> month ago.
>
> https://lore.kernel.org/all/20240222-spmi-multi-master-support-v6-0-bc34ea9561da@linaro.org/
Ykes, you are right.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Krzysztof Kozlowski @ 2024-03-27 10:43 UTC (permalink / raw)
To: Yu-chang Lee (李禹璋),
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <b957b072d5d88ed315982e914a7f700e0ccafb83.camel@mediatek.com>
On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
>>>>
>>> Hi,
>>>
>>> I will double check the format of yaml for the next version, sorry
>> for
>>> inconvenience. But I did test it on mt8188 chromebook, the reason
>> why
>>
>> How do you test a binding on chromebook?
>>
>>> power domain need larb node is that when mtcmos power on, signal
>> glitch
>>> may produce. Power domain driver must reset larb when this happen
>> to
>>> prevent dummy transaction on bus. That why I need larb node in dts.
>>
>> No one talks here about larb node...
>
> Sorry, May you elaborate on what information I need to provide to you
> or it is just a syntax problem I need to fix?
Please explain the purpose of this property (how is it going to be used
by drivers) and what does it represent.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-27 10:39 UTC (permalink / raw)
To: krzysztof.kozlowski@linaro.org,
MandyJH Liu (劉人僖), conor+dt@kernel.org,
robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
matthias.bgg@gmail.com, ulf.hansson@linaro.org,
angelogioacchino.delregno@collabora.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <7ff9c4c7-3b56-4a5b-95b7-c37cbf8bcd6d@linaro.org>
On Wed, 2024-03-27 at 10:59 +0100, Krzysztof Kozlowski wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> On 27/03/2024 10:34, Yu-chang Lee (李禹璋) wrote:
> > On Wed, 2024-03-27 at 10:23 +0100, Krzysztof Kozlowski wrote:
> >>
> >> External email : Please do not click links or open attachments
> until
> >> you have verified the sender or the content.
> >> On 27/03/2024 09:39, Krzysztof Kozlowski wrote:
> >>> On 27/03/2024 06:57, yu-chang.lee wrote:
> >>>> Add Smart Multimedia Interface Local Arbiter to mediatek
> >>>> power domain.
> >>>>
> >>>> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
> >>>> ---
> >>>> .../devicetree/bindings/power/mediatek,power-controller.yaml |
> 4
> >> ++++
> >>>> 1 file changed, 4 insertions(+)
> >>>>
> >>>> diff --git
> >> a/Documentation/devicetree/bindings/power/mediatek,power-
> >> controller.yaml
> >> b/Documentation/devicetree/bindings/power/mediatek,power-
> >> controller.yaml
> >>>> index 8985e2df8a56..228c0dec5253 100644
> >>>> --- a/Documentation/devicetree/bindings/power/mediatek,power-
> >> controller.yaml
> >>>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-
> >> controller.yaml
> >>>> @@ -125,6 +125,10 @@ $defs:
> >>>> $ref: /schemas/types.yaml#/definitions/phandle
> >>>> description: phandle to the device containing the SMI
> >> register range.
> >>>>
> >>>> + mediatek,larb:
> >>>> + $ref: /schemas/types.yaml#/definitions/phandle
> >>>> + description: phandle to the device containing the LARB
> >> register range.
> >>>
> >>> Why do you need it?
> >>>
> >>> Plus I also see mediatek,larbs and mediatek,larb-id... so now we
> >> have
> >>> third one similar.
> >>
> >> ... and not even tested!
> >>
> >> Best regards,
> >> Krzysztof
> >>
> > Hi,
> >
> > I will double check the format of yaml for the next version, sorry
> for
> > inconvenience. But I did test it on mt8188 chromebook, the reason
> why
>
> How do you test a binding on chromebook?
>
> > power domain need larb node is that when mtcmos power on, signal
> glitch
> > may produce. Power domain driver must reset larb when this happen
> to
> > prevent dummy transaction on bus. That why I need larb node in dts.
>
> No one talks here about larb node...
Sorry, May you elaborate on what information I need to provide to you
or it is just a syntax problem I need to fix?
Thanks
Best Regards,
Yu-chang
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH RESEND v6 0/5] spmi: pmic-arb: Add support for multiple buses
From: Abel Vesa @ 2024-03-27 10:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Srini Kandagatla,
Johan Hovold, linux-kernel, linux-arm-kernel, linux-arm-msm,
linux-mediatek, devicetree
In-Reply-To: <d213f262-ba0e-4cf8-af0e-66745ffea429@linaro.org>
On 24-03-27 10:23:51, Krzysztof Kozlowski wrote:
> On 26/03/2024 17:28, Abel Vesa wrote:
> > This RFC prepares for and adds support for 2 buses, which is supported
> > in HW starting with version 7. Until now, none of the currently
> > supported platforms in upstream have used the second bus. The X1E80100
> > platform, on the other hand, needs the second bus for the USB2.0 to work
> > as there are 3 SMB2360 PMICs which provide eUSB2 repeaters and they are
> > all found on the second bus.
> >
> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> > ---
> > Changes in v6:
> > - Changed the compatible to platform specific (X1E80100) along with the
> > schema. Fixed the spmi buses unit addresses and added the empty ranges
>
> Why resending after few days? And why without reviews?
>
If you are referring to the initial v6 patchset, it was sent more than a
month ago.
https://lore.kernel.org/all/20240222-spmi-multi-master-support-v6-0-bc34ea9561da@linaro.org/
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: rockchip: quartzpro64: Enable the GPU
From: Heiko Stübner @ 2024-03-27 10:29 UTC (permalink / raw)
To: linux-rockchip, Dragan Simic
Cc: linux-arm-kernel, devicetree, robh+dt, krzysztof.kozlowski+dt,
conor+dt, boris.brezillon, linux-kernel, kernel,
sebastian.reichel
In-Reply-To: <0f3759ee390f245dac447bbee038445ddfecbec0.1711383286.git.dsimic@manjaro.org>
Hi,
Am Montag, 25. März 2024, 17:19:04 CET schrieb Dragan Simic:
> Following the approach used to enable the Mali GPU on the rk3588-evb1, [1]
> do the same for the Pine64 QuartzPro64, which uses nearly identical hardware
> design as the RK3588 EVB1.
>
> The slight disadvantage is that the regulator coupling logic requires the
> regulators to be always on, which is also noted in the comments. This is
> obviously something to be improved at some point in the future, but should
> be fine for now, especially because the QuartzPro64 isn't a battery-powered
> board, so low power consumption isn't paramount.
>
> [1] https://lore.kernel.org/linux-rockchip/20240325153850.189128-5-sebastian.reichel@collabora.com/
>
> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
as lore.kernel.org and therefore b4 seems to be on vacation today, you
get a very personal "applied" message ;-) .
So, applied for 6.10 after the core rk3588-gpu-series from Sebastian.
Heiko
^ permalink raw reply
* Re: [PATCH v2 0/4] RK3588 GPU support
From: Heiko Stuebner @ 2024-03-27 10:28 UTC (permalink / raw)
To: linux-rockchip, Sebastian Reichel
Cc: Heiko Stuebner, kernel, devicetree, Boris Brezillon,
Krzysztof Kozlowski, linux-kernel, Conor Dooley, Rob Herring
In-Reply-To: <20240326165232.73585-1-sebastian.reichel@collabora.com>
On Tue, 26 Mar 2024 17:52:04 +0100, Sebastian Reichel wrote:
> Panthor has landed in linux-next including the DT bindings, so it is
> time to add the necessary DT changes to support the GPU on RK3588.
> This adds support at SoC level and support for the EVB1 as well as
> the Rock 5B, which covers both variants found in RK3588 boards:
>
> 1. Having dedicated regulators for GPU core and GPU memory. This
> is handled by coupling both regulators.
> 2. Having a shared regulator for GPU core and GPU memory.
>
> [...]
Applied, thanks!
[1/4] arm64: defconfig: support Mali CSF-based GPUs
commit: e6968faa33ce754bbe36dd6d9fe6951ec10616b1
[2/4] arm64: dts: rockchip: rk3588: Add GPU nodes
commit: 6fca4edb93d335f29f81e484936f38a5eed6a9b1
[3/4] arm64: dts: rockchip: rk3588-rock5b: Enable GPU
commit: 038347286941148b6fd0cc2c40afcd540315aa6f
[4/4] arm64: dts: rockchip: rk3588-evb1: Enable GPU
commit: 75a287219a782951e671026ed4fbe611e4629c83
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Krzysztof Kozlowski @ 2024-03-27 10:19 UTC (permalink / raw)
To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <6af08a38-5239-4f5f-9e87-108e3400a6e6@solid-run.com>
On 26/03/2024 20:26, Josua Mayer wrote:
> Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski:
>> On 25/03/2024 21:12, Josua Mayer wrote:
>>> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski:
>>>> On 22/03/2024 11:08, Josua Mayer wrote:
>>>>> Am 21.03.24 um 22:47 schrieb Josua Mayer:
>>>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on
>>>>>> CN9130 SoC.
>>>>>> The carrier boards are identical to the older Armada 388 based Clearfog
>>>>>> boards. For consistency the carrier part of compatible strings are
>>>>>> copied, including the established "-a1" suffix.
>>>>>>
>>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++
>>>>>> 1 file changed, 12 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>> index 16d2e132d3d1..36bdfd1bedd9 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>> @@ -82,4 +82,16 @@ properties:
>>>>>> - const: marvell,armada-ap807-quad
>>>>>> - const: marvell,armada-ap807
>>>>>>
>>>>>> + - description:
>>>>>> + SolidRun CN9130 clearfog family single-board computers
>>>>>> + items:
>>>>>> + - enum:
>>>>>> + - solidrun,clearfog-base-a1
>>>>>> + - solidrun,clearfog-pro-a1
>>>>>> + - const: solidrun,clearfog-a1
>>>>>> + - const: solidrun,cn9130-sr-som
>>>>>> + - const: marvell,cn9130
>>>>>> + - const: marvell,armada-ap807-quad
>>>>>> + - const: marvell,armada-ap807
>>>>>> +
>>>>>> additionalProperties: true
>>>>> Before merging I would like some feedback about adding
>>>>> another product later, to ensure the compatibles above
>>>>> are adequate? In particular:
>>>>> - sequence of soc, cp, carrier compatibles
>>>>> - name of som compatible
>>>>>
>>>>> Draft for future bindings:
>>>>> - description:
>>>>> SolidRun CN9130 SoM based single-board computers
>>>>> with 1 external CP on the Carrier.
>>>>> items:
>>>>> - enum:
>>>>> - solidrun,cn9131-solidwan
>>>>> - const: marvell,cn9131
>>>>> - const: solidrun,cn9130-sr-som
>>>> This does not look correct. cn9131 is not compatible with your som.
>>> This is partially my question.
>>> I considered changing the som to "cn913x-sr-som".
>>>
>>> The SoM itself is always 9130, it contains the base SoC
>>> with 1x AP and 1x CP in a single chip.
>>> 9131 and 9132 <happen> on the carrier boards.
>> No wildcards, but if the SoM name is 9130 then use 9130.
>> The problem is that you use cn9130 SoC as fallback.
>>
>>>>> - const: marvell,cn9130
>>>> SoCs are compatible only in some cases, e.g. one is a subset of another
>>>> like stripped out of modem. Are you sure this is your case?
>>> This is more complex, CN9131 and CN9132 are not single SoCs.
>>> A "9132" is instantiated by connecting two southbridge chips
>>> via a Marvell defined bus, each providing additional IO
>>> such as network, i2c, gpio.
>>>
>>> Note that even the first, "9130", while a single chip, contains two dies:
>>> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c),
>>> and a "CP" (Communication Processor I assume) with lots of IO.
>>> This CP as far as I know today is identical to the southbridges
>>> mentioned above.
>> OK, but how does it affect compatibility between them? Which parts are
>> the same? Or how much is shared?
> 9130, 9131, 9132 belong together.
I don't understand what it means.
> 9130 is single chip including two dies: AP, CP.
> The CP is available as an individual chip,
> up to two can be connected to one 9130.
And? How does it help me to decide? What is 9131 and 9132?
>
> What does this mean for compatibility?
> Which compatibility specifically?
> Is there a definition we can refer to?
Devicetree spec.
Let me answer with a question, because you neither answer mine nor
provide detailed information.
Is Cortex-A15 compatible with Cortex-A7 in the Devicetree? No. Now what
does it mean to your case?
I don't even understand what is your case.
>
> From software perspective we can always down-grade,
> i.e. run software only aware of the AP on 9130, 9131 or 9132.
> But we can't run software referencing the external CPs
> if they are not connected.
Same with Cortex A15 and A7, right?
>
>>>>> - const: marvell,armada-ap807-quad
>>>>> - const: marvell,armada-ap807
>>>> Anyway, 6 compatibles is beyond useful amount. What are you expressing
>>>> here?
>>> I copied this part from the examples earlier in the file, such as:
>>> - description: Armada CN9132 SoC with two external CPs
>>> items:
>>> - const: marvell,cn9132
>>> - const: marvell,cn9131
>>> - const: marvell,cn9130
>>> - const: marvell,armada-ap807-quad
>>> - const: marvell,armada-ap807
>>>> Why is this even armada ap807?
>>> We noticed ap807 != ap806 (cn913x != 8040),
>>> because the thermal sensor coefficients converting
>>> raw values to celsius differed.
>> That's also not the best example.Might be correct but also looks
>> over-complicated. The point of board-level compatibles is to identify
>> machine and its common parts. It has little impact inside of kernel (at
>> least should be almost no users inside!)
> Indeed, the temperature coefficients are handled by the thermal device
> compatible string, not board-level.
>> , but there can be some users,
>> e.g. firmware or user-space.
>>
>> This claims that cn9132 is compatible with ap807, so you have exactly
>> the same base. The same base is not CPU! It's about the S in SoC, so
>> "System".
> I would think since the base is always a single chip combining 1x AP+CP,
> the "system" is marvell,cn9130.
> For Armada 8040, the system would be marvell,armada8040 by same
> logic (also combining 1x AP+CP, different version, not extensible).
>> Could firmware use marvell,armada-ap807 compatible to properly
>> detect type of system and treat all these boards as ap807?
> I have not looked into presence detection for CP's during initialization.
> U-Boot support without spaghetti is a future Me task.
???
> I suspect it is possible with asterisk *, because so far I have only seen
> configuration with at least 1 CP, never with 0.
> Presence of a boot-rom on each die e.g. supports this idea.
I still don't understand.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 7/7] regulator: mcp16502: Update the names from buck regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
andrei.simion, devicetree, linux-arm-kernel, linux-kernel
Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>
Use generic names for buck regulators to avoid any confusion.
Update the names from buck regulators in order to match
the datasheet block diagram for the buck regulators.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
drivers/regulator/mcp16502.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/mcp16502.c b/drivers/regulator/mcp16502.c
index 0c15a19fe83a..d6fc9f1afaef 100644
--- a/drivers/regulator/mcp16502.c
+++ b/drivers/regulator/mcp16502.c
@@ -468,13 +468,13 @@ static const struct linear_range b234_ranges[] = {
static const struct regulator_desc mcp16502_desc[] = {
/* MCP16502_REGULATOR(_name, _id, ranges, regulator_ops, ramp_table) */
- MCP16502_REGULATOR("VDD_IO", BUCK1, b1l12_ranges, mcp16502_buck_ops,
+ MCP16502_REGULATOR("BUCK1", BUCK1, b1l12_ranges, mcp16502_buck_ops,
mcp16502_ramp_b1l12),
- MCP16502_REGULATOR("VDD_DDR", BUCK2, b234_ranges, mcp16502_buck_ops,
+ MCP16502_REGULATOR("BUCK2", BUCK2, b234_ranges, mcp16502_buck_ops,
mcp16502_ramp_b234),
- MCP16502_REGULATOR("VDD_CORE", BUCK3, b234_ranges, mcp16502_buck_ops,
+ MCP16502_REGULATOR("BUCK3", BUCK3, b234_ranges, mcp16502_buck_ops,
mcp16502_ramp_b234),
- MCP16502_REGULATOR("VDD_OTHER", BUCK4, b234_ranges, mcp16502_buck_ops,
+ MCP16502_REGULATOR("BUCK4", BUCK4, b234_ranges, mcp16502_buck_ops,
mcp16502_ramp_b234),
MCP16502_REGULATOR("LDO1", LDO1, b1l12_ranges, mcp16502_ldo_ops,
mcp16502_ramp_b1l12),
--
2.44.0
^ permalink raw reply related
* [PATCH 5/7] ARM: dts: microchip: sama7g5ek: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
andrei.simion, devicetree, linux-arm-kernel, linux-kernel
Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>
Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama7g5ek.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts b/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
index 217e9b96c61e..5a9b8b6dd0df 100644
--- a/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
@@ -242,7 +242,7 @@ mcp16502@5b {
status = "okay";
regulators {
- vdd_3v3: VDD_IO {
+ vdd_3v3: BUCK1 {
regulator-name = "VDD_IO";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -262,7 +262,7 @@ regulator-state-mem {
};
};
- vddioddr: VDD_DDR {
+ vddioddr: BUCK2 {
regulator-name = "VDD_DDR";
regulator-min-microvolt = <1350000>;
regulator-max-microvolt = <1350000>;
@@ -283,7 +283,7 @@ regulator-state-mem {
};
};
- vddcore: VDD_CORE {
+ vddcore: BUCK3 {
regulator-name = "VDD_CORE";
regulator-min-microvolt = <1150000>;
regulator-max-microvolt = <1150000>;
@@ -303,7 +303,7 @@ regulator-state-mem {
};
};
- vddcpu: VDD_OTHER {
+ vddcpu: BUCK4 {
regulator-name = "VDD_OTHER";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1250000>;
--
2.44.0
^ permalink raw reply related
* [PATCH 6/7] regulator: dt-bindings: microchip,mcp16502: Update the node names from buck regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
andrei.simion, devicetree, linux-arm-kernel, linux-kernel
Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>
Update the node names from buck regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
.../bindings/regulator/microchip,mcp16502.yaml | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml b/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
index 1aca3646789e..72a1f8a92949 100644
--- a/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
+++ b/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
@@ -34,7 +34,7 @@ properties:
description: List of regulators and its properties.
patternProperties:
- "^(VDD_(IO|CORE|DDR|OTHER)|LDO[1-2])$":
+ "^(BUCK[1-4]|LDO[1-2])$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
@@ -70,7 +70,7 @@ examples:
reg = <0x5b>;
regulators {
- VDD_IO {
+ BUCK1 {
regulator-name = "VDD_IO";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -89,7 +89,7 @@ examples:
};
};
- VDD_DDR {
+ BUCK2 {
regulator-name = "VDD_DDR";
regulator-min-microvolt = <1350000>;
regulator-max-microvolt = <1350000>;
@@ -108,7 +108,7 @@ examples:
};
};
- VDD_CORE {
+ BUCK3 {
regulator-name = "VDD_CORE";
regulator-min-microvolt = <1150000>;
regulator-max-microvolt = <1150000>;
@@ -127,7 +127,7 @@ examples:
};
};
- VDD_OTHER {
+ BUCK4 {
regulator-name = "VDD_OTHER";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1250000>;
--
2.44.0
^ permalink raw reply related
* [PATCH 3/7] ARM: dts: microchip: sama5d2_icp: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
andrei.simion, devicetree, linux-arm-kernel, linux-kernel
Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>
Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts b/arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts
index 999adeca6f33..f20de8180381 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts
@@ -194,7 +194,7 @@ mcp16502@5b {
lpm-gpios = <&pioBU 7 GPIO_ACTIVE_LOW>;
regulators {
- vdd_io_reg: VDD_IO {
+ vdd_io_reg: BUCK1 {
regulator-name = "VDD_IO";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -213,7 +213,7 @@ regulator-state-mem {
};
};
- VDD_DDR {
+ BUCK2 {
regulator-name = "VDD_DDR";
regulator-min-microvolt = <1350000>;
regulator-max-microvolt = <1350000>;
@@ -232,7 +232,7 @@ regulator-state-mem {
};
};
- VDD_CORE {
+ BUCK3 {
regulator-name = "VDD_CORE";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <1250000>;
@@ -251,7 +251,7 @@ regulator-state-mem {
};
};
- VDD_OTHER {
+ BUCK4 {
regulator-name = "VDD_OTHER";
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <1850000>;
--
2.44.0
^ permalink raw reply related
* [PATCH 2/7] ARM: dts: microchip: sama5d29_curiosity: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
andrei.simion, devicetree, linux-arm-kernel, linux-kernel
Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>
Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts b/arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts
index 6b02b7bcfd49..b1874ae8dfc2 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts
@@ -148,7 +148,7 @@ mcp16502@5b {
lpm-gpios = <&pioBU 0 GPIO_ACTIVE_LOW>;
regulators {
- vdd_3v3: VDD_IO {
+ vdd_3v3: BUCK1 {
regulator-name = "VDD_IO";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -167,7 +167,7 @@ regulator-state-mem {
};
};
- vddio_ddr: VDD_DDR {
+ vddio_ddr: BUCK2 {
regulator-name = "VDD_DDR";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
@@ -190,7 +190,7 @@ regulator-state-mem {
};
};
- vdd_core: VDD_CORE {
+ vdd_core: BUCK3 {
regulator-name = "VDD_CORE";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <1250000>;
@@ -209,7 +209,7 @@ regulator-state-mem {
};
};
- vdd_ddr: VDD_OTHER {
+ vdd_ddr: BUCK4 {
regulator-name = "VDD_OTHER";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
--
2.44.0
^ permalink raw reply related
* [PATCH 1/7] ARM: dts: microchip: sama5d27_wlsom1: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
andrei.simion, devicetree, linux-arm-kernel, linux-kernel
Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>
Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
index 4617805c7748..228382f630cc 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
@@ -74,7 +74,7 @@ mcp16502@5b {
lpm-gpios = <&pioBU 0 GPIO_ACTIVE_LOW>;
regulators {
- vdd_3v3: VDD_IO {
+ vdd_3v3: BUCK1 {
regulator-name = "VDD_IO";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -93,7 +93,7 @@ regulator-state-mem {
};
};
- vddio_ddr: VDD_DDR {
+ vddio_ddr: BUCK2 {
regulator-name = "VDD_DDR";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
@@ -116,7 +116,7 @@ regulator-state-mem {
};
};
- vdd_core: VDD_CORE {
+ vdd_core: BUCK3 {
regulator-name = "VDD_CORE";
regulator-min-microvolt = <1250000>;
regulator-max-microvolt = <1250000>;
@@ -135,7 +135,7 @@ regulator-state-mem {
};
};
- vdd_ddr: VDD_OTHER {
+ vdd_ddr: BUCK4 {
regulator-name = "VDD_OTHER";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
--
2.44.0
^ permalink raw reply related
* [PATCH 4/7] ARM: dts: microchip: sama7g54_curiosity: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
andrei.simion, devicetree, linux-arm-kernel, linux-kernel
Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>
Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts b/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
index 4f609e9e510e..a83a6fd3f5fa 100644
--- a/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
@@ -191,7 +191,7 @@ pmic@5b {
reg = <0x5b>;
regulators {
- vdd_3v3: VDD_IO {
+ vdd_3v3: BUCK1 {
regulator-name = "VDD_IO";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -211,7 +211,7 @@ regulator-state-mem {
};
};
- vddioddr: VDD_DDR {
+ vddioddr: BUCK2 {
regulator-name = "VDD_DDR";
regulator-min-microvolt = <1350000>;
regulator-max-microvolt = <1350000>;
@@ -232,7 +232,7 @@ regulator-state-mem {
};
};
- vddcore: VDD_CORE {
+ vddcore: BUCK3 {
regulator-name = "VDD_CORE";
regulator-min-microvolt = <1150000>;
regulator-max-microvolt = <1150000>;
@@ -252,7 +252,7 @@ regulator-state-mem {
};
};
- vddcpu: VDD_OTHER {
+ vddcpu: BUCK4 {
regulator-name = "VDD_OTHER";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1250000>;
--
2.44.0
^ permalink raw reply related
* [PATCH 0/7] regulator: mcp16502: Update the names from buck regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
andrei.simion, devicetree, linux-arm-kernel, linux-kernel
Cc: Mihai Sain
Use generic names for buck regulators to avoid any confusion.
Update the names from buck regulators in order to match
the datasheet block diagram for the buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.
Link: https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP16502-Data-Sheet-DS20006275.pdf
Mihai Sain (7):
ARM: dts: microchip: sama5d27_wlsom1: Update the node names from pmic-regulators
ARM: dts: microchip: sama5d29_curiosity: Update the node names from pmic-regulators
ARM: dts: microchip: sama5d2_icp: Update the node names from pmic-regulators
ARM: dts: microchip: sama7g54_curiosity: Update the node names from pmic-regulators
ARM: dts: microchip: sama7g5ek: Update the node names from pmic-regulators
regulator: dt-bindings: microchip,mcp16502: Update the node names from buck regulators
regulator: mcp16502: Update the names from buck regulators
.../bindings/regulator/microchip,mcp16502.yaml | 10 +++++-----
arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi | 8 ++++----
.../arm/boot/dts/microchip/at91-sama5d29_curiosity.dts | 8 ++++----
arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts | 8 ++++----
.../arm/boot/dts/microchip/at91-sama7g54_curiosity.dts | 8 ++++----
arch/arm/boot/dts/microchip/at91-sama7g5ek.dts | 8 ++++----
drivers/regulator/mcp16502.c | 8 ++++----
7 files changed, 29 insertions(+), 29 deletions(-)
--
2.44.0
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
From: Krzysztof Kozlowski @ 2024-03-27 10:11 UTC (permalink / raw)
To: Dmitry Baryshkov, Rob Clark, Abhinav Kumar, Sean Paul,
Marijn Suijten, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Vinod Koul
Cc: linux-arm-msm, dri-devel, freedreno, devicetree
In-Reply-To: <20240326-fd-fix-schema-v1-1-4475d6d6d633@linaro.org>
On 26/03/2024 21:02, Dmitry Baryshkov wrote:
> As Qualcomm SM8150 got support for the DisplayPort, add displayport@
> node as a valid child to the MDSS node.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display/msm: sm8150-mdss: add DP node
From: Krzysztof Kozlowski @ 2024-03-27 10:11 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie,
Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Vinod Koul, linux-arm-msm,
dri-devel, freedreno, devicetree
In-Reply-To: <CAA8EJprg55BkRL5KUZ+6gNniq9TZjEem8MLqQdMZcXntvttEVg@mail.gmail.com>
On 27/03/2024 09:52, Dmitry Baryshkov wrote:
> On Wed, 27 Mar 2024 at 10:45, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 26/03/2024 21:02, Dmitry Baryshkov wrote:
>>> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
>>> index c0d6a4fdff97..40b077fb20aa 100644
>>> --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
>>> +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8150-mdss.yaml
>>> @@ -53,6 +53,16 @@ patternProperties:
>>> compatible:
>>> const: qcom,sm8150-dpu
>>>
>>> + "^displayport-controller@[0-9a-f]+$":
>>> + type: object
>>> + additionalProperties: true
>>> +
>>> + properties:
>>> + compatible:
>>> + items:
>>> + - const: qcom,sm8150-dp
>>> + - const: qcom,sm8350-dp
>>
>> This does not look right. sm8350 has its own mdss binding file.
>
> So just a single entry here, even though SM8150 uses fallback compat string?
Ah, wait, I misread, I thought it is enum.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox