* Re: [PATCH v3 07/14] drm/mediatek: Rename files "mtk_drm_crtc.c" to "mtk_crtc.c"
From: AngeloGioacchino Del Regno @ 2024-03-20 9:08 UTC (permalink / raw)
To: Shawn Sung, Chun-Kuang Hu
Cc: Philipp Zabel, David Airlie, Daniel Vetter, Matthias Brugger,
Sumit Semwal, Christian König, dri-devel, linux-mediatek,
linux-kernel, linux-arm-kernel, linux-media, linaro-mm-sig,
Hsiao Chien Sung
In-Reply-To: <20240320024222.14234-8-shawn.sung@mediatek.com>
Il 20/03/24 03:42, Shawn Sung ha scritto:
> From: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
>
> Rename files mtk_drm_crtc.c to mtk_crtc.c and
> modify the Makefile accordingly.
>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8] dt-bindings: ata: imx-pata: Convert to dtschema
From: Animesh Agarwal @ 2024-03-20 9:07 UTC (permalink / raw)
Cc: animeshagarwal28, Damien Le Moal, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team, linux-ide,
devicetree, linux-arm-kernel, linux-kernel
Convert the imx-pata bindings to DT schema.
Add missing fsl,imx31-pata and fsl,imx51-pata compatibles during
conversion, because they are already being used in existing DTS.
Signed-off-by: Animesh Agarwal <animeshagarwal28@gmail.com>
---
Changes in v8:
- added missing space after comma in examples' compatible property
Changes in v7:
- removed blank space at the end of file.
Changes in v6:
- removed items before const due to single element.
Changes in v5:
- added oneOf in compatible property to allow the usage of imx27 alone.
Changes in v4:
- added fsl,imx31-pata in compatible property as enum.
Changes in v3:
- added fsl,imx51-pata in compatible property as enum
- fsl,imx27-pata is added as a const to ensure it is present always
Changes in v2:
- fixed style issues
- compatible property now matches the examples
- fixed yamllint warnings/errors
---
.../devicetree/bindings/ata/fsl,imx-pata.yaml | 42 +++++++++++++++++++
.../devicetree/bindings/ata/imx-pata.txt | 16 -------
2 files changed, 42 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml
delete mode 100644 Documentation/devicetree/bindings/ata/imx-pata.txt
diff --git a/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml b/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml
new file mode 100644
index 000000000000..324e2413bba8
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/fsl,imx-pata.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/ata/fsl,imx-pata.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX PATA Controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx31-pata
+ - fsl,imx51-pata
+ - const: fsl,imx27-pata
+ - const: fsl,imx27-pata
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: PATA Controller interrupts
+
+ clocks:
+ items:
+ - description: PATA Controller clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ pata: pata@83fe0000 {
+ compatible = "fsl,imx51-pata", "fsl,imx27-pata";
+ reg = <0x83fe0000 0x4000>;
+ interrupts = <70>;
+ clocks = <&clks 161>;
+ };
diff --git a/Documentation/devicetree/bindings/ata/imx-pata.txt b/Documentation/devicetree/bindings/ata/imx-pata.txt
deleted file mode 100644
index f1172f00188a..000000000000
--- a/Documentation/devicetree/bindings/ata/imx-pata.txt
+++ /dev/null
@@ -1,16 +0,0 @@
-* Freescale i.MX PATA Controller
-
-Required properties:
-- compatible: "fsl,imx27-pata"
-- reg: Address range of the PATA Controller
-- interrupts: The interrupt of the PATA Controller
-- clocks: the clocks for the PATA Controller
-
-Example:
-
- pata: pata@83fe0000 {
- compatible = "fsl,imx51-pata", "fsl,imx27-pata";
- reg = <0x83fe0000 0x4000>;
- interrupts = <70>;
- clocks = <&clks 161>;
- };
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] drivers: watchdog: ast2600 support bootstatus
From: PeterYin @ 2024-03-20 9:05 UTC (permalink / raw)
To: Guenter Roeck, patrick, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Wim Van Sebroeck,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-watchdog
In-Reply-To: <13640a07-7395-4521-9c5d-748599202361@roeck-us.net>
Guenter Roeck 於 3/19/24 08:46 寫道:
> On 3/17/24 22:52, Peter Yin wrote:
>> Add WDIOF_EXTERN1 and WDIOF_CARDRESET bootstatus in ast2600
>>
>> Regarding the AST2600 specification, the WDTn Timeout Status Register
>> (WDT10) has bit 1 reserved. To verify the second boot source,
>> we need to check SEC14 bit 12 and bit 13.
>> The bits 8-23 in the WDTn Timeout Status Register are the Watchdog
>> Event Count, which we can use to verify WDIOF_EXTERN1.
>>
>> Signed-off-by: Peter Yin <peteryin.openbmc@gmail.com>
>
> You'll have to separate dts and yaml file changes from driver changes.
>
>> ---
>> Change log:
>>
>> v1 -> v2
>> - Add comment and support WDIOF_CARDRESET in ast2600
>>
>> v1
>> - Patch 0001 - Add WDIOF_EXTERN1 bootstatus
>> ---
>> arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 8 ++---
>> drivers/watchdog/aspeed_wdt.c | 45 ++++++++++++++++++++++---
>> 2 files changed, 44 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
>> b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
>> index e0b44498269f..23ae7f0430e9 100644
>> --- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
>> +++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
>> @@ -556,24 +556,24 @@ uart5: serial@1e784000 {
>> wdt1: watchdog@1e785000 {
>> compatible = "aspeed,ast2600-wdt";
>> - reg = <0x1e785000 0x40>;
>> + reg = <0x1e785000 0x40>, <0x1e6f2000 0x20>;
>> };
>> wdt2: watchdog@1e785040 {
>> compatible = "aspeed,ast2600-wdt";
>> - reg = <0x1e785040 0x40>;
>> + reg = <0x1e785040 0x40>, <0x1e6f2000 0x020>;
>> status = "disabled";
>> };
>> wdt3: watchdog@1e785080 {
>> compatible = "aspeed,ast2600-wdt";
>> - reg = <0x1e785080 0x40>;
>> + reg = <0x1e785080 0x40>, <0x1e6f2000 0x020>;
>> status = "disabled";
>> };
>> wdt4: watchdog@1e7850c0 {
>> compatible = "aspeed,ast2600-wdt";
>> - reg = <0x1e7850C0 0x40>;
>> + reg = <0x1e7850C0 0x40>, <0x1e6f2000 0x020>;
>> status = "disabled";
>> };
>> diff --git a/drivers/watchdog/aspeed_wdt.c
>> b/drivers/watchdog/aspeed_wdt.c
>> index b4773a6aaf8c..65118e461130 100644
>> --- a/drivers/watchdog/aspeed_wdt.c
>> +++ b/drivers/watchdog/aspeed_wdt.c
>> @@ -33,6 +33,7 @@ struct aspeed_wdt {
>> void __iomem *base;
>> u32 ctrl;
>> const struct aspeed_wdt_config *cfg;
>> + void __iomem *sec_base;
>> };
>> static const struct aspeed_wdt_config ast2400_config = {
>> @@ -82,6 +83,15 @@ MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
>> #define WDT_RESET_MASK1 0x1c
>> #define WDT_RESET_MASK2 0x20
>> +/*
>> + * Only Ast2600 support
>> + */
>> +#define WDT_EVENT_COUNTER_MASK (0xFFF << 8)
>> +#define WDT_SECURE_ENGINE_STATUS (0x14)
>> +#define ABR_IMAGE_SOURCE BIT(12)
>> +#define ABR_IMAGE_SOURCE_SPI BIT(13)
>> +#define SECOND_BOOT_ENABLE BIT(14)
>> +
>> /*
>> * WDT_RESET_WIDTH controls the characteristics of the external
>> pulse (if
>> * enabled), specifically:
>> @@ -313,6 +323,7 @@ static int aspeed_wdt_probe(struct platform_device
>> *pdev)
>> const char *reset_type;
>> u32 duration;
>> u32 status;
>> + u32 sec_st;
>> int ret;
>> wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
>> @@ -330,6 +341,12 @@ static int aspeed_wdt_probe(struct
>> platform_device *pdev)
>> if (IS_ERR(wdt->base))
>> return PTR_ERR(wdt->base);
>> + if (of_device_is_compatible(np, "aspeed,ast2600-wdt")) {
>> + wdt->sec_base = devm_platform_ioremap_resource(pdev, 1);
>> + if (IS_ERR(wdt->sec_base))
>> + return PTR_ERR(wdt->sec_base);
>> + }
>> +
>> wdt->wdd.info = &aspeed_wdt_info;
>> if (wdt->cfg->irq_mask) {
>> @@ -459,12 +476,30 @@ static int aspeed_wdt_probe(struct
>> platform_device *pdev)
>> }
>> status = readl(wdt->base + WDT_TIMEOUT_STATUS);
>> - if (status & WDT_TIMEOUT_STATUS_BOOT_SECONDARY) {
>> - wdt->wdd.bootstatus = WDIOF_CARDRESET;
>> - if (of_device_is_compatible(np, "aspeed,ast2400-wdt") ||
>> - of_device_is_compatible(np, "aspeed,ast2500-wdt"))
>> - wdt->wdd.groups = bswitch_groups;
>> + if (of_device_is_compatible(np, "aspeed,ast2600-wdt")) {
>> + /*
>> + * The WDTn Timeout Status Register bit 1 is reserved.
>> + * To verify the second boot source,
>> + * we need to check SEC14 bit 12 and bit 13.
>> + */
>> + sec_st = readl(wdt->sec_base + WDT_SECURE_ENGINE_STATUS);
>> + if( sec_st & SECOND_BOOT_ENABLE)
>> + if (sec_st & ABR_IMAGE_SOURCE ||
>> + sec_st & ABR_IMAGE_SOURCE_SPI)
>
> I am sure that checkpatch as something to say here. Either case, I would
> very
> much prefer a single if() statement such as
>
> if (sec_st & SECOND_BOOT_ENABLE &&
> sec_st & (ABR_IMAGE_SOURCE | ABR_IMAGE_SOURCE_SPI))
>
>> + wdt->wdd.bootstatus |= WDIOF_CARDRESET;
>> +
>> + /*
>> + * To check Watchdog Event Count for WDIOF_EXTERN1
>> + */
>> + if (status & WDT_EVENT_COUNTER_MASK) {
>> + wdt->wdd.bootstatus |= WDIOF_EXTERN1;
>> + }
>
> Unnecessary { }
>
> ... but does this really indicate that there was a reset due to some
> event ?
> This reads three 8-bit counters. Wouldn't it make more sense to check bit 0
> instead ?
>
> I am also not sure if reading the watchdog status from
> WDT_SECURE_ENGINE_STATUS
> adds any value over the status reported in the watchdog status register.
> You'll have to explain why the added complexity is necessary or even adds
> value.
>
> Never mind, though ...
>
> Looking into the datasheets, the current code is quite completely wrong
> anyway.
> Bit 1 of the status register indicates on ast2500 if the boot was from
> the second
> boot source. It does not indicate that the most recent reset was
> triggered by
> the watchdog. The code should just be changed to set WDIOF_CARDRESET if
> bit 0
> of the status register is set. The boot source is out of scope for the
> watchdog
> status bits.
>
> Thanks,
> Guenter
>
Ast2600 has external reset flag on scu74 bit 1
Can I modify the code like this?
To set WDIOF_EXTERN1 if EXTERN_RESET_FLAG is set,
To set WDIOF_CARDRESET if WDT_TIMEOUT_STATUS_EVENT(bit0) is set
#define WDT_TIMEOUT_STATUS_EVENT BIT(0)
#define EXTERN_RESET_FLAG BIT(1)
#define ASPEED_SYSTEM_RESET_EVENT (0x74)
status = readl(wdt->base + WDT_TIMEOUT_STATUS);
if (status & WDT_TIMEOUT_STATUS_EVENT)
wdt->wdd.bootstatus = WDIOF_CARDRESET;
if (of_device_is_compatible(np, "aspeed,ast2600-wdt")) {
status = readl(wdt->scu_base + ASPEED_SYSTEM_RESET_EVENT);
if (status & EXTERN_RESET_FLAG)
/*
* Reset cause by Extern Reset
*/
wdt->wdd.bootstatus |= WDIOF_EXTERN1;
} else {
wdt->wdd.groups = bswitch_groups;
}
Thanks,
Peter.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/5] media: platform: mediatek: isp_30: add mediatek ISP3.0 sensor interface
From: CK Hu (胡俊光) @ 2024-03-20 9:04 UTC (permalink / raw)
To: jstephan@baylibre.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
robh+dt@kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, paul.elder@ideasonboard.com,
mchehab@kernel.org, conor+dt@kernel.org,
Andy Hsieh (謝智皓),
Louis Kuo (郭德寧),
krzysztof.kozlowski+dt@linaro.org,
linux-arm-kernel@lists.infradead.org,
laurent.pinchart@ideasonboard.com, fsylvestre@baylibre.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
pnguyen@baylibre.com
In-Reply-To: <20240110141443.364655-4-jstephan@baylibre.com>
Hi, Julien:
On Wed, 2024-01-10 at 15:14 +0100, Julien Stephan wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> From: Louis Kuo <louis.kuo@mediatek.com>
>
> This will add the mediatek ISP3.0 seninf (sensor interface) driver
> found
> on several Mediatek SoCs such as the mt8365.
>
> Then seninf module has 4 physical CSI-2 inputs. Depending on the soc
> they
> may not be all connected.
>
> Signed-off-by: Louis Kuo <louis.kuo@mediatek.com>
> Signed-off-by: Phi-bang Nguyen <pnguyen@baylibre.com>
> Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com>
> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Co-developed-by: Julien Stephan <jstephan@baylibre.com>
> Signed-off-by: Julien Stephan <jstephan@baylibre.com>
> ---
[snip]
> +
> +static const struct mtk_seninf_conf seninf_8365_conf = {
> + .model = "mtk-camsys-3.0",
> + .nb_inputs = 4,
> + .nb_muxes = 6,
> + .nb_outputs = 4,
> +};
I think you should directly define these value as symbols because now
only support one SoC.
#define MODEL "mtk-camsys-3.0"
#define INPUT_NR 4
#define MUTEX_NR 6
#define OUTPUT_NR 4
Because we don't know which SoC would be upstream later, maybe the next
SoC would be
static const struct mtk_seninf_conf seninf_83xx_conf = {
.model = "mtk-camsys-3.0",
.nb_inputs = 4,
.nb_muxes = 6,
.nb_outputs = 4,
.support_xxx = true;
};
then model, nb_inputs, nb_muxes, and nb_outputs has no difference, so
it's not necessary to define them as variable. So define them as
constant now, and when next SoC upstream, then we know which one would
be variable.
Regards,
CK
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] random: Fix the issue of '_might_sleep' function running in an atomic contex
From: Guoyong Wang @ 2024-03-20 9:02 UTC (permalink / raw)
To: Jason A . Donenfeld, Theodore Ts'o, Tejun Heo, Lai Jiangshan,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
Guoyong Wang
In-Reply-To: <Zfo3QUFEy4wHkLEB@zx2c4.com>
On Web, 20 Mar 2024 02:09:21 +0100, Jason A. Donenfeld wrote:
>> Hi Jason,
>>
>> Thanks for your suggestions.
>>
>> I am inclined to accept your second suggestion. My reluctance to accept
>> the first is due to the concern that "&& !in_atomic()" could potentially
>> alter the original meaning of the 'execute_in_process_context' interface.
>> Regarding the third suggestion, modifying the logic associated with 'input'
>> is not recommended.
>
> Doesn't something like the below seem simplest? Just move the call out
> of the spinlock and we're done.
>
> diff --git a/drivers/input/input-core-private.h b/drivers/input/input-core-private.h
> index 116834cf8868..717f239e28d0 100644
> --- a/drivers/input/input-core-private.h
> +++ b/drivers/input/input-core-private.h
> @@ -10,7 +10,7 @@
> struct input_dev;
>
> void input_mt_release_slots(struct input_dev *dev);
> -void input_handle_event(struct input_dev *dev,
> +bool input_handle_event(struct input_dev *dev,
> unsigned int type, unsigned int code, int value);
>
> #endif /* _INPUT_CORE_PRIVATE_H */
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index f71ea4fb173f..2faf46218c66 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -391,20 +391,22 @@ static void input_event_dispose(struct input_dev *dev, int disposition,
> }
> }
>
> -void input_handle_event(struct input_dev *dev,
> +bool input_handle_event(struct input_dev *dev,
> unsigned int type, unsigned int code, int value)
> {
> int disposition;
> +bool should_contribute_to_rng = false;
>
> lockdep_assert_held(&dev->event_lock);
>
> disposition = input_get_disposition(dev, type, code, &value);
> if (disposition != INPUT_IGNORE_EVENT) {
> if (type != EV_SYN)
> -add_input_randomness(type, code, value);
> +should_contribute_to_rng = true;
>
> input_event_dispose(dev, disposition, type, code, value);
> }
> +return should_contribute_to_rng;
> }
>
> /**
> @@ -428,12 +430,15 @@ void input_event(struct input_dev *dev,
> unsigned int type, unsigned int code, int value)
> {
> unsigned long flags;
> +bool should_contribute_to_rng;
>
> if (is_event_supported(type, dev->evbit, EV_MAX)) {
>
> spin_lock_irqsave(&dev->event_lock, flags);
> -input_handle_event(dev, type, code, value);
> +should_contribute_to_rng = input_handle_event(dev, type, code, value);
> spin_unlock_irqrestore(&dev->event_lock, flags);
> +if (should_contribute_to_rng)
> +add_input_randomness(type, code, value);
> }
> }
> EXPORT_SYMBOL(input_event);
Hi Jason,
Your proposal is not suitable for scenarios where input_event is called within an atomic context.
For example:
spin_lock(&dev->spinlock);
input_event(dev, EV_ABS, ABS_X, x);
spin_unlock(&dev->spinlock);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 11/13] regulator: tps51632: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/tps51632-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps51632-regulator.c b/drivers/regulator/tps51632-regulator.c
index 5199e0437388..3a384bf9d2c5 100644
--- a/drivers/regulator/tps51632-regulator.c
+++ b/drivers/regulator/tps51632-regulator.c
@@ -199,7 +199,7 @@ static const struct regmap_config tps51632_regmap_config = {
.readable_reg = is_read_reg,
.volatile_reg = is_volatile_reg,
.max_register = TPS51632_MAX_REG - 1,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
#if defined(CONFIG_OF)
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 06/13] regulator: pca9450: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/pca9450-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/pca9450-regulator.c b/drivers/regulator/pca9450-regulator.c
index 2ab365d2749f..8781e58b74f7 100644
--- a/drivers/regulator/pca9450-regulator.c
+++ b/drivers/regulator/pca9450-regulator.c
@@ -53,7 +53,7 @@ static const struct regmap_config pca9450_regmap_config = {
.val_bits = 8,
.volatile_table = &pca9450_volatile_regs,
.max_register = PCA9450_MAX_REGISTER - 1,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
/*
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 05/13] regulator: mt6311: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/mt6311-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/mt6311-regulator.c b/drivers/regulator/mt6311-regulator.c
index 63a51485f2cc..c00638cd2d1e 100644
--- a/drivers/regulator/mt6311-regulator.c
+++ b/drivers/regulator/mt6311-regulator.c
@@ -20,7 +20,7 @@ static const struct regmap_config mt6311_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = MT6311_FQMTR_CON4,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
/* Default limits measured in millivolts and milliamps */
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 08/13] regulator: pfuze100: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/pfuze100-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/pfuze100-regulator.c b/drivers/regulator/pfuze100-regulator.c
index 46854602b3ea..7c04870442d3 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -680,7 +680,7 @@ static const struct regmap_config pfuze_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = PFUZE_NUMREGS - 1,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
static int pfuze100_regulator_probe(struct i2c_client *client)
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 09/13] regulator: rtmv20: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/rtmv20-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/rtmv20-regulator.c b/drivers/regulator/rtmv20-regulator.c
index dfd1522637e4..3d8d29f87b58 100644
--- a/drivers/regulator/rtmv20-regulator.c
+++ b/drivers/regulator/rtmv20-regulator.c
@@ -312,7 +312,7 @@ static bool rtmv20_is_volatile_reg(struct device *dev, unsigned int reg)
static const struct regmap_config rtmv20_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.max_register = RTMV20_REG_LDMASK,
.num_reg_defaults_raw = RTMV20_MAX_REGS,
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 04/13] regulator: max8973: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/max8973-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max8973-regulator.c b/drivers/regulator/max8973-regulator.c
index f8bb6828feef..96ca146281d6 100644
--- a/drivers/regulator/max8973-regulator.c
+++ b/drivers/regulator/max8973-regulator.c
@@ -510,7 +510,7 @@ static const struct regmap_config max8973_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = MAX8973_CHIPID2,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
static struct max8973_regulator_platform_data *max8973_parse_dt(
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 02/13] regulator: da9211: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/da9211-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/da9211-regulator.c b/drivers/regulator/da9211-regulator.c
index af383ff0fe57..d8b39ea3de0e 100644
--- a/drivers/regulator/da9211-regulator.c
+++ b/drivers/regulator/da9211-regulator.c
@@ -68,7 +68,7 @@ static const struct regmap_config da9211_regmap_config = {
.val_bits = 8,
.max_register = 5 * 128,
.volatile_reg = da9211_volatile_reg,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.ranges = da9211_regmap_range,
.num_ranges = ARRAY_SIZE(da9211_regmap_range),
};
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 10/13] regulator: rtq6752: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/rtq6752-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/rtq6752-regulator.c b/drivers/regulator/rtq6752-regulator.c
index 8176e5ab0683..d35d844eff3b 100644
--- a/drivers/regulator/rtq6752-regulator.c
+++ b/drivers/regulator/rtq6752-regulator.c
@@ -209,7 +209,7 @@ static const struct reg_default rtq6752_reg_defaults[] = {
static const struct regmap_config rtq6752_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.max_register = RTQ6752_REG_FAULT,
.reg_defaults = rtq6752_reg_defaults,
.num_reg_defaults = ARRAY_SIZE(rtq6752_reg_defaults),
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 01/13] regulator: da9121: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/da9121-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/da9121-regulator.c b/drivers/regulator/da9121-regulator.c
index 5ee76b533576..96257551bb12 100644
--- a/drivers/regulator/da9121-regulator.c
+++ b/drivers/regulator/da9121-regulator.c
@@ -872,7 +872,7 @@ static struct regmap_config da9121_1ch_regmap_config = {
.rd_table = &da9121_1ch_readable_table,
.wr_table = &da9121_1ch_writeable_table,
.volatile_table = &da9121_volatile_table,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
/* DA9121 regmap config for 2 channel variants */
@@ -883,7 +883,7 @@ static struct regmap_config da9121_2ch_regmap_config = {
.rd_table = &da9121_2ch_readable_table,
.wr_table = &da9121_2ch_writeable_table,
.volatile_table = &da9121_volatile_table,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
static int da9121_check_device_type(struct i2c_client *i2c, struct da9121 *chip)
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 07/13] regulator: pf8x00: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/pf8x00-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/pf8x00-regulator.c b/drivers/regulator/pf8x00-regulator.c
index b0781d9a1058..9fd8e0949b32 100644
--- a/drivers/regulator/pf8x00-regulator.c
+++ b/drivers/regulator/pf8x00-regulator.c
@@ -142,7 +142,7 @@ static const struct regmap_config pf8x00_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = PF8X00_PAGE_SELECT,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
/* VLDOx output: 1.5V to 5.0V */
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 00/13] regulator: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Bo Liu (13):
regulator: da9121: convert to use maple tree register cache
regulator: da9211: convert to use maple tree register cache
regulator: isl9305: convert to use maple tree register cache
regulator: max8973: convert to use maple tree register cache
regulator: mt6311: convert to use maple tree register cache
regulator: pca9450: convert to use maple tree register cache
regulator: pf8x00: convert to use maple tree register cache
regulator: pfuze100: convert to use maple tree register cache
regulator: rtmv20: convert to use maple tree register cache
regulator: rtq6752: convert to use maple tree register cache
regulator: tps51632: convert to use maple tree register cache
regulator: tps62360: convert to use maple tree register cache
regulator: rpi-panel-attiny: convert to use maple tree register cache
drivers/regulator/da9121-regulator.c | 4 ++--
drivers/regulator/da9211-regulator.c | 2 +-
drivers/regulator/isl9305.c | 2 +-
drivers/regulator/max8973-regulator.c | 2 +-
drivers/regulator/mt6311-regulator.c | 2 +-
drivers/regulator/pca9450-regulator.c | 2 +-
drivers/regulator/pf8x00-regulator.c | 2 +-
drivers/regulator/pfuze100-regulator.c | 2 +-
drivers/regulator/rpi-panel-attiny-regulator.c | 2 +-
drivers/regulator/rtmv20-regulator.c | 2 +-
drivers/regulator/rtq6752-regulator.c | 2 +-
drivers/regulator/tps51632-regulator.c | 2 +-
drivers/regulator/tps62360-regulator.c | 2 +-
13 files changed, 14 insertions(+), 14 deletions(-)
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 13/13] regulator: rpi-panel-attiny: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/rpi-panel-attiny-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/rpi-panel-attiny-regulator.c b/drivers/regulator/rpi-panel-attiny-regulator.c
index f52c3d47ecea..6c3b6bfac961 100644
--- a/drivers/regulator/rpi-panel-attiny-regulator.c
+++ b/drivers/regulator/rpi-panel-attiny-regulator.c
@@ -75,7 +75,7 @@ static const struct regmap_config attiny_regmap_config = {
.val_bits = 8,
.disable_locking = 1,
.max_register = REG_WRITE_DATA_L,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
static int attiny_set_port_state(struct attiny_lcd *state, int reg, u8 val)
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 12/13] regulator: tps62360: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/tps62360-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps62360-regulator.c b/drivers/regulator/tps62360-regulator.c
index 32e1a05a57fd..be6a6702cbfa 100644
--- a/drivers/regulator/tps62360-regulator.c
+++ b/drivers/regulator/tps62360-regulator.c
@@ -275,7 +275,7 @@ static const struct regmap_config tps62360_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = REG_CHIPID,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
static struct tps62360_regulator_platform_data *
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 03/13] regulator: isl9305: convert to use maple tree register cache
From: Bo Liu @ 2024-03-20 8:57 UTC (permalink / raw)
To: support.opensource, lgirdwood, broonie, matthias.bgg,
angelogioacchino.delregno, jagan
Cc: linux-kernel, linux-arm-kernel, linux-mediatek, Bo Liu
In-Reply-To: <20240320085740.4604-1-liubo03@inspur.com>
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Bo Liu <liubo03@inspur.com>
---
drivers/regulator/isl9305.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/isl9305.c b/drivers/regulator/isl9305.c
index 0f7560093091..5a234f25e6bb 100644
--- a/drivers/regulator/isl9305.c
+++ b/drivers/regulator/isl9305.c
@@ -134,7 +134,7 @@ static const struct regmap_config isl9305_regmap = {
.val_bits = 8,
.max_register = ISL9305_MAX_REG,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
static int isl9305_i2c_probe(struct i2c_client *i2c)
--
2.18.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/4] dt-bindings: media: Add bindings for raspberrypi,rp1-cfe
From: Naushir Patuck @ 2024-03-20 8:50 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Krzysztof Kozlowski, linux-media, linux-kernel, devicetree,
linux-rpi-kernel, linux-arm-kernel, Laurent Pinchart,
Sakari Ailus, Jacopo Mondi, Kieran Bingham, Mauro Carvalho Chehab,
Raspberry Pi Kernel Maintenance, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list
In-Reply-To: <b95fb19d-1c22-45b2-8b87-78e56d17ae8e@ideasonboard.com>
On Tue, 19 Mar 2024 at 17:05, Tomi Valkeinen
<tomi.valkeinen@ideasonboard.com> wrote:
>
> On 19/03/2024 17:32, Naushir Patuck wrote:
> > On Tue, 19 Mar 2024 at 14:03, Tomi Valkeinen
> > <tomi.valkeinen@ideasonboard.com> wrote:
> >>
> >> On 19/03/2024 15:05, Naushir Patuck wrote:
> >>> On Tue, 19 Mar 2024 at 13:02, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>
> >>>> On 19/03/2024 13:57, Naushir Patuck wrote:
> >>>>>>>>
> >>>>>>>> See writing bindings. Compatibles should be SoC specific. In some cases
> >>>>>>>> generic fallbacks make sense, in some note. But don't just choose
> >>>>>>>> "generic fallback" because you want. Provide rationale.
> >>>>>>>
> >>>>>>> If the compatible is SoC specific, I suppose "raspberrypi,rp1-cfe"
> >>>>>>> would be the correct string.
> >>>>>>
> >>>>>> Sure, but then please think what if rp1 is on Rpi6, called exactly the
> >>>>>> same (rp1), with some minor differences? Could it be?
> >>>>>
> >>>>> Yes, this is definitely possible. In such cases, I would expect the
> >>>>> hardware to have a version register that would be queried by the
> >>>>> driver to adjust for minor differences, and the compatible string
> >>>>> remains the same. Does that seem reasonable?
> >>>>
> >>>> The "would expect" is concerning. The register(s) must be there already,
> >>>> with proper value.
> >>>>
> >>>
> >>> A version register already exists in the current hardware, so we will
> >>> update it to identify future hardware revisions.
> >>
> >> But that's a version register for the FE block, not for the whole
> >> module, right? Are you suggesting that you'll make sure the FE version
> >> will be changed every time anything in the bigger CFE block is changed,
> >> and thus the FE version would also reflect the whole CFE version?
> >
> > Yes, we will update the FE versioning when either CSI2 / FE blocks are updated.
> >
> >>
> >> Can there be versions without the FE block, with just the CSI-2 parts?
> >
> > There is no version register just in the CSI2 block in isolation, so
> > this is not possible.
>
> I meant could there be a future RPx with only the CSI-2 parts on it, no
> FE? In which case we would not have any register for the version. But
> then, that would be a rather big change, so a different compatible
> string would be in order.
>
> So, while it's not exactly a perfect version register, I think it will
> work fine, assuming the HW people will actually increase the version
> also for changes outside FE.
>
> >>
> >> Also, I'm still wondering about the RP1 part there in the compatible
> >> string. Is it necessary? The CFE is located in the RP1 co-processor, but
> >> is that relevant?
> >>
> >> Is there a versioning for the whole RP1 chip? Maybe it's going to the
> >> wrong direction if we use the board/SoC for this compatible name, as
> >> it's actually the RP1 where the CFE is located in, not the SoC.
> >>
> >
> > I don't really know the conversion required to answer this one.
> > Logically CFE is on RP1, so it makes sense to me to have "rp1" in the
> > string, but I will follow the judgment of the maintainers.
>
> Well, my thinking here was that if we have a register from which to read
> the version, and Raspberry Pi would create a new co-processor, RP2, with
> the same CFE. Would we then have "raspberrypi,rp1-cfe" and
> "raspberrypi,rp2-cfe", even if there are no changes? Or would a plain
> "raspberrypi,cfe" do for both?
>
> In other words, if we don't need the "rp1" for versioning purposes,
> should it then be dropped?
I agree with the above, you've convinced me that "raspberrypi,cfe"
might be the more appropriate string, or a convincing argument for
that to be a fallback string.
Naush
>
> On the other hand, maybe it is safer to just keep the "rp1" there anyway...
>
> Tomi
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM: unwind: improve unwinders for noreturn case
From: Russell King (Oracle) @ 2024-03-20 8:45 UTC (permalink / raw)
To: Jiangfeng Xiao
Cc: arnd, keescook, haibo.li, angelogioacchino.delregno, amergnat,
akpm, dave.hansen, douzhaolei, gustavoars, jpoimboe,
kepler.chenxin, kirill.shutemov, linux-hardening, linux-kernel,
linux-mm, linux-arm-kernel, nixiaoming, peterz, wangbing6,
wangfangpeng1, jannh, willy, David.Laight
In-Reply-To: <1710906278-23851-1-git-send-email-xiaojiangfeng@huawei.com>
On Wed, Mar 20, 2024 at 11:44:38AM +0800, Jiangfeng Xiao wrote:
> This is an off-by-one bug which is common in unwinders,
> due to the fact that the address on the stack points
> to the return address rather than the call address.
>
> So, for example, when the last instruction of a function
> is a function call (e.g., to a noreturn function), it can
> cause the unwinder to incorrectly try to unwind from
> the function after the callee.
>
> foo:
> ...
> bl bar
> ... end of function and thus next function ...
>
> which results in LR pointing into the next function.
>
> Fixed this by subtracting 1 from frmae->pc in the call frame
> (but not exception frames) like ORC on x86 does.
The reason that I'm not accepting this patch is because the above says
that it fixes it by subtracting 1 from the PC value, but the patch is
*way* more complicated than that and there's no explanation why.
For example, the following are unexplained:
- Why do we always need ex_frame
- What is the purpose of the change in format string for the display of
backtraces
>
> Refer to the unwind_next_frame function in the unwind_orc.c
>
> Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org>
> Link: https://lkml.kernel.org/lkml/20240305175846.qnyiru7uaa7itqba@treble/
> Signed-off-by: Jiangfeng Xiao <xiaojiangfeng@huawei.com>
> ---
> ChangeLog v1->v2
> - stay printk("%s...", loglvl, ...)
> ---
> arch/arm/include/asm/stacktrace.h | 4 ----
> arch/arm/kernel/stacktrace.c | 2 --
> arch/arm/kernel/traps.c | 4 ++--
> arch/arm/kernel/unwind.c | 18 +++++++++++++++---
> 4 files changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/include/asm/stacktrace.h b/arch/arm/include/asm/stacktrace.h
> index 360f0d2..07e4c16 100644
> --- a/arch/arm/include/asm/stacktrace.h
> +++ b/arch/arm/include/asm/stacktrace.h
> @@ -21,9 +21,7 @@ struct stackframe {
> struct llist_node *kr_cur;
> struct task_struct *tsk;
> #endif
> -#ifdef CONFIG_UNWINDER_FRAME_POINTER
> bool ex_frame;
> -#endif
> };
>
> static __always_inline
> @@ -37,9 +35,7 @@ void arm_get_current_stackframe(struct pt_regs *regs, struct stackframe *frame)
> frame->kr_cur = NULL;
> frame->tsk = current;
> #endif
> -#ifdef CONFIG_UNWINDER_FRAME_POINTER
> frame->ex_frame = in_entry_text(frame->pc);
> -#endif
> }
>
> extern int unwind_frame(struct stackframe *frame);
> diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
> index 620aa82..1abd4f9 100644
> --- a/arch/arm/kernel/stacktrace.c
> +++ b/arch/arm/kernel/stacktrace.c
> @@ -154,9 +154,7 @@ static void start_stack_trace(struct stackframe *frame, struct task_struct *task
> frame->kr_cur = NULL;
> frame->tsk = task;
> #endif
> -#ifdef CONFIG_UNWINDER_FRAME_POINTER
> frame->ex_frame = in_entry_text(frame->pc);
> -#endif
> }
>
> void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 3bad79d..46a5b1e 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -84,10 +84,10 @@ void dump_backtrace_entry(unsigned long where, unsigned long from,
> printk("%sFunction entered at [<%08lx>] from [<%08lx>]\n",
> loglvl, where, from);
> #elif defined CONFIG_BACKTRACE_VERBOSE
> - printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pS)\n",
> + printk("%s[<%08lx>] (%ps) from [<%08lx>] (%pB)\n",
> loglvl, where, (void *)where, from, (void *)from);
> #else
> - printk("%s %ps from %pS\n", loglvl, (void *)where, (void *)from);
> + printk("%s %ps from %pB\n", loglvl, (void *)where, (void *)from);
> #endif
>
> if (in_entry_text(from) && end <= ALIGN(frame, THREAD_SIZE))
> diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
> index 9d21921..f2baf92 100644
> --- a/arch/arm/kernel/unwind.c
> +++ b/arch/arm/kernel/unwind.c
> @@ -30,6 +30,7 @@
> #include <linux/list.h>
> #include <linux/module.h>
>
> +#include <asm/sections.h>
> #include <asm/stacktrace.h>
> #include <asm/traps.h>
> #include <asm/unwind.h>
> @@ -416,8 +417,14 @@ int unwind_frame(struct stackframe *frame)
>
> pr_debug("%s(pc = %08lx lr = %08lx sp = %08lx)\n", __func__,
> frame->pc, frame->lr, frame->sp);
> -
> - idx = unwind_find_idx(frame->pc);
> + /*
> + * For a call frame (as opposed to a exception frame), when the last
> + * instruction of a function is a function call (e.g., to a noreturn
> + * function), it can cause the unwinder incorrectly try to unwind
> + * from the function after the callee, fixed this by subtracting 1
> + * from frame->pc in the call frame like ORC on x86 does.
> + */
> + idx = unwind_find_idx(frame->ex_frame ? frame->pc : frame->pc - 1);
> if (!idx) {
> if (frame->pc && kernel_text_address(frame->pc)) {
> if (in_module_plt(frame->pc) && frame->pc != frame->lr) {
> @@ -427,6 +434,7 @@ int unwind_frame(struct stackframe *frame)
> * the state of the stack or the register file
> */
> frame->pc = frame->lr;
> + frame->ex_frame = in_entry_text(frame->pc);
> return URC_OK;
> }
> pr_warn("unwind: Index not found %08lx\n", frame->pc);
> @@ -454,6 +462,7 @@ int unwind_frame(struct stackframe *frame)
> if (frame->pc == frame->lr)
> return -URC_FAILURE;
> frame->pc = frame->lr;
> + frame->ex_frame = in_entry_text(frame->pc);
> return URC_OK;
> } else if ((idx->insn & 0x80000000) == 0)
> /* prel31 to the unwind table */
> @@ -515,6 +524,7 @@ int unwind_frame(struct stackframe *frame)
> frame->lr = ctrl.vrs[LR];
> frame->pc = ctrl.vrs[PC];
> frame->lr_addr = ctrl.lr_addr;
> + frame->ex_frame = in_entry_text(frame->pc);
>
> return URC_OK;
> }
> @@ -544,6 +554,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
> */
> here:
> frame.pc = (unsigned long)&&here;
> + frame.ex_frame = false;
> } else {
> /* task blocked in __switch_to */
> frame.fp = thread_saved_fp(tsk);
> @@ -554,11 +565,12 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk,
> */
> frame.lr = 0;
> frame.pc = thread_saved_pc(tsk);
> + frame.ex_frame = false;
> }
>
> while (1) {
> int urc;
> - unsigned long where = frame.pc;
> + unsigned long where = frame.ex_frame ? frame.pc : frame.pc - 1;
>
> urc = unwind_frame(&frame);
> if (urc < 0)
> --
> 1.8.5.6
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] dt-bindings: i2c: nxp,pnx-i2c: Convert to dtschema
From: Animesh Agarwal @ 2024-03-20 8:46 UTC (permalink / raw)
Cc: animeshagarwal28, Conor Dooley, Vladimir Zapolskiy, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
linux-i2c, devicetree, linux-kernel
Convert the NXP PNX I2C Controller bindings to DT schema.
Keep only one example in DT schema to remove redundancy.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Animesh Agarwal <animeshagarwal28@gmail.com>
---
Changes in v3:
- Added a missing whitespace character in maintainers.
- Added parent directory in subject prefix.
Changes in v2:
- Changed the file name from nxp,i2c-pnx.yaml to nxp,pnx-i2c.yaml.
- Dropped properties which were already defined in the top level $ref.
- Dropped unused labels in example.
---
.../devicetree/bindings/i2c/i2c-pnx.txt | 34 --------------
.../devicetree/bindings/i2c/nxp,pnx-i2c.yaml | 46 +++++++++++++++++++
2 files changed, 46 insertions(+), 34 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-pnx.txt
create mode 100644 Documentation/devicetree/bindings/i2c/nxp,pnx-i2c.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pnx.txt b/Documentation/devicetree/bindings/i2c/i2c-pnx.txt
deleted file mode 100644
index 2a59006cf79e..000000000000
--- a/Documentation/devicetree/bindings/i2c/i2c-pnx.txt
+++ /dev/null
@@ -1,34 +0,0 @@
-* NXP PNX I2C Controller
-
-Required properties:
-
- - reg: Offset and length of the register set for the device
- - compatible: should be "nxp,pnx-i2c"
- - interrupts: configure one interrupt line
- - #address-cells: always 1 (for i2c addresses)
- - #size-cells: always 0
-
-Optional properties:
-
- - clock-frequency: desired I2C bus clock frequency in Hz, Default: 100000 Hz
-
-Examples:
-
- i2c1: i2c@400a0000 {
- compatible = "nxp,pnx-i2c";
- reg = <0x400a0000 0x100>;
- interrupt-parent = <&mic>;
- interrupts = <51 0>;
- #address-cells = <1>;
- #size-cells = <0>;
- };
-
- i2c2: i2c@400a8000 {
- compatible = "nxp,pnx-i2c";
- reg = <0x400a8000 0x100>;
- interrupt-parent = <&mic>;
- interrupts = <50 0>;
- #address-cells = <1>;
- #size-cells = <0>;
- clock-frequency = <100000>;
- };
diff --git a/Documentation/devicetree/bindings/i2c/nxp,pnx-i2c.yaml b/Documentation/devicetree/bindings/i2c/nxp,pnx-i2c.yaml
new file mode 100644
index 000000000000..798a6939b894
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nxp,pnx-i2c.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/nxp,pnx-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP PNX I2C Controller
+
+maintainers:
+ - Animesh Agarwal <animeshagarwal28@gmail.com>
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: nxp,pnx-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ default: 100000
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#address-cells"
+ - "#size-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c@400a0000 {
+ compatible = "nxp,pnx-i2c";
+ reg = <0x400a0000 0x100>;
+ interrupt-parent = <&mic>;
+ interrupts = <51 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 02/18] pinctrl: pinctrl-single: move suspend()/resume() callbacks to noirq
From: Thomas Richard @ 2024-03-20 8:37 UTC (permalink / raw)
To: Dhruva Gole
Cc: Linus Walleij, Bartosz Golaszewski, Andy Shevchenko,
Tony Lindgren, Haojian Zhuang, Vignesh R, Aaro Koskinen,
Janusz Krzysztofik, Andi Shyti, Peter Rosin, Vinod Koul,
Kishon Vijay Abraham I, Philipp Zabel, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, linux-gpio,
linux-kernel, linux-arm-kernel, linux-omap, linux-i2c, linux-phy,
linux-pci, gregory.clement, theo.lebrun, thomas.petazzoni,
u-kumar1, Andy Shevchenko
In-Reply-To: <20240320074431.6yzao3jlyaxuii7c@dhruva>
On 3/20/24 08:44, Dhruva Gole wrote:
> Hi,
>
> On Mar 04, 2024 at 16:35:45 +0100, Thomas Richard wrote:
>> The goal is to extend the active period of pinctrl.
>> Some devices may need active pinctrl after suspend() and/or before
>> resume().
>> So move suspend()/resume() to suspend_noirq()/resume_noirq() in order to
>> have active pinctrl until suspend_noirq() (included), and from
>> resume_noirq() (included).
>>
>> The deprecated API has been removed to use the new one (dev_pm_ops struct).
>>
>> No need to check the pointer returned by dev_get_drvdata(), as
>> platform_set_drvdata() is called during the probe.
>>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
>> ---
>
> I was planning to do this but didn't see particular benefit to it. Do
> you see the benefit on your specific device? Can you help me understand
> how? Not against the patch, just curious.
Hello Dhruva,
We need this patch to support suspend to ram for the PCIe on J7200.
In root complex mode, a gpio is used to reset endpoints.
This gpio shall be managed during suspend_noirq and resume_noirq stages.
On J7200 this gpio is on a gpio expander.
So we need this patch to restore pinctrl to be able to do i2c accesses
in noirq stages.
Best Regards,
--
Thomas Richard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: renesas: Add more TMU support
From: Wolfram Sang @ 2024-03-20 8:34 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Niklas Söderlund, linux-renesas-soc,
linux-arm-kernel
In-Reply-To: <CAMuHMdWeq6c8F=i7SgEt+HBBpknaEFTsrxM26OrDpjzOS_YTZw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 394 bytes --]
Hi Geert,
> > Huh? It works on Lager and fails on Koelsch? Do you have a log file?
>
> Of course it succeeded on the next try...
Interesting. I will try Lager then and see if it fails there as well. It
is only TMU3, right?
> Perhaps a subtle driver issue, or an issue with the test?
My gut feeling says "the latter", but I have no real proof.
Happy hacking,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: nxp,pnx-i2c: Convert to dtschema
From: Animesh Agarwal @ 2024-03-20 8:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Conor Dooley, Vladimir Zapolskiy, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, linux-i2c,
devicetree, linux-kernel
In-Reply-To: <2b45017a-5a68-4c56-a1b3-ef17163139d4@linaro.org>
On Wed, Mar 20, 2024 at 1:23 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> Yes.
>
> While at this:
> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.
> missing i2c
Thanks for the support on this, I will be using proper subject
prefixes here onwards.
> This is an automated instruction, just in case, because many review tags
> are being ignored. If you know the process, you can skip it (please do
> not feel offended by me posting it here - no bad intentions intended).
> If you do not know the process, here is a short explanation:
>
> Please add Acked-by/Reviewed-by/Tested-by tags when posting new
> versions, under or above your Signed-off-by tag. Tag is "received", when
> provided in a message replied to you on the mailing list. Tools like b4
> can help here. However, there's no need to repost patches *only* to add
> the tags. The upstream maintainer will do that for tags received on the
> version they apply.
>
> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
Yes, I'll follow these instructions for v3 of this patch.
Regards,
Animesh Agarwal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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