* Re: [PATCH v2 1/1] arm: dts: sunxi: Add ICnova A20 ADB4006 board support
From: Ludwig Kormann @ 2023-04-20 9:22 UTC (permalink / raw)
To: Andre Przywara
Cc: samuel, jernej.skrabec, wens, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-sunxi, linux-kernel
In-Reply-To: <20230420095735.00cbf365@donnerap.cambridge.arm.com>
Hi Andre,
Am 20.04.23 um 10:57 schrieb Andre Przywara:
> On Wed, 19 Apr 2023 14:12:29 +0200
> Ludwig Kormann <ludwig.kormann@in-circuit.de> wrote:
>
> Hi Ludwig,
>
> thanks for posting this!
>
>> Add board support for ICnova A20 SomPi compute module on
>> ICnova ADB4006 development board.
>>
>> Specification:
>> SoM
>> - Processor: Allwinner A20 Cortex-A7 Dual Core at 1GHz
>> - 512MB DDR3 RAM
>> - Fast Ethernet (Phy: Realtek RTL8201CP)
>> ADB4006
>> - I2C
>> - 2x USB 2.0
>> - 1x Fast Ethernet port
>> - 1x SATA
>> - 2x buttons (PWRON, Boot)
>> - 2x LEDS
>> - serial console
>> - HDMI
>> - µSD-Card slot
>> - Audio Line-In / Line-Out
>> - GPIO pinheaders
>>
>> https://wiki.in-circuit.de/index.php5?title=ICnova_ADB4006
>> https://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
>>
>> ---
>>
>> changes in v2:
>> - use short licensing header
>> - remove deprecated elements from led nodes
>> - disable csi power supply
>> - add missing pins in usbphy node
>> - split dts into SoM dtsi and carrier board dts
>>
>> v1 of this patch was sent to the uboot mailing list [1].
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2023-April/514605.html
>>
>> Signed-off-by: Ludwig Kormann <ludwig.kormann@in-circuit.de>
> So apart from what Krzysztof already mentioned (separate binding patch and
> stray line), this looks good to me, and passed dt-validate. Also you
> addressed all the comments I had on the U-Boot post (thanks for that), so
> with those nits above fixed:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Thanks for your review! I will provide v3 in a few minutes.
kind regards,
Ludwig
> Cheers,
> Andre
>
>> ---
>> .../devicetree/bindings/arm/sunxi.yaml | 6 +
>> arch/arm/boot/dts/Makefile | 1 +
>> .../boot/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++++++++++++++++++
>> arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi | 63 ++++++++
>> 4 files changed, 207 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
>> index 013821f4a7b8..12f0c236f17b 100644
>> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml
>> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
>> @@ -305,6 +305,12 @@ properties:
>> - const: allwinner,i12-tvbox
>> - const: allwinner,sun7i-a20
>>
>> + - description: ICNova A20 ADB4006
>> + items:
>> + - const: incircuit,icnova-a20-adb4006
>> + - const: incircuit,icnova-a20
>> + - const: allwinner,sun7i-a20
>> +
>> - description: ICNova A20 SWAC
>> items:
>> - const: incircuit,icnova-a20-swac
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 3cc32722c394..b6b408417261 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -1321,6 +1321,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
>> sun7i-a20-hummingbird.dtb \
>> sun7i-a20-itead-ibox.dtb \
>> sun7i-a20-i12-tvbox.dtb \
>> + sun7i-a20-icnova-a20-adb4006.dtb \
>> sun7i-a20-icnova-swac.dtb \
>> sun7i-a20-lamobo-r1.dtb \
>> sun7i-a20-linutronix-testbox-v2.dtb \
>> diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> new file mode 100644
>> index 000000000000..c1606c085e4e
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
>> @@ -0,0 +1,137 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +// Copyright (C) 2023 In-Circuit GmbH
>> +
>> +/dts-v1/;
>> +
>> +#include "sun7i-a20-icnova-a20.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/leds/common.h>
>> +
>> +/ {
>> + model = "In-Circuit ICnova A20 ADB4006";
>> + compatible = "incircuit,icnova-a20-adb4006", "incircuit,icnova-a20",
>> + "allwinner,sun7i-a20";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + hdmi-connector {
>> + compatible = "hdmi-connector";
>> + type = "a";
>> +
>> + port {
>> + hdmi_con_in: endpoint {
>> + remote-endpoint = <&hdmi_out_con>;
>> + };
>> + };
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led-0 {
>> + function = LED_FUNCTION_POWER;
>> + color = <LED_COLOR_ID_YELLOW>;
>> + gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; /* PH21 */
>> + default-state = "on";
>> + };
>> +
>> + led-1 {
>> + function = LED_FUNCTION_HEARTBEAT;
>> + color = <LED_COLOR_ID_RED>;
>> + gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
>> + linux,default-trigger = "heartbeat";
>> + };
>> + };
>> +};
>> +
>> +&ahci {
>> + target-supply = <®_ahci_5v>;
>> + status = "okay";
>> +};
>> +
>> +&codec {
>> + status = "okay";
>> +};
>> +
>> +&de {
>> + status = "okay";
>> +};
>> +
>> +&ehci0 {
>> + status = "okay";
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&hdmi {
>> + status = "okay";
>> +};
>> +
>> +&hdmi_out {
>> + hdmi_out_con: endpoint {
>> + remote-endpoint = <&hdmi_con_in>;
>> + };
>> +};
>> +
>> +&mmc0 {
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
>> + status = "okay";
>> +};
>> +
>> +&ohci0 {
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&otg_sram {
>> + status = "okay";
>> +};
>> +
>> +®_ahci_5v {
>> + status = "okay";
>> +};
>> +
>> +&ac_power_supply {
>> + status = "okay";
>> +};
>> +
>> +®_usb1_vbus {
>> + status = "okay";
>> +};
>> +
>> +®_usb2_vbus {
>> + status = "okay";
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_pb_pins>;
>> + status = "okay";
>> +};
>> +
>> +&usb_otg {
>> + dr_mode = "otg";
>> + status = "okay";
>> +};
>> +
>> +&usbphy {
>> + usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
>> + usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
>> + usb1_vbus-supply = <®_usb1_vbus>;
>> + usb2_vbus-supply = <®_usb2_vbus>;
>> + status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi b/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
>> new file mode 100644
>> index 000000000000..f1142bda5cd7
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
>> @@ -0,0 +1,63 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +// Copyright (C) 2023 In-Circuit GmbH
>> +
>> +#include "sun7i-a20.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +
>> +&cpu0 {
>> + cpu-supply = <®_dcdc2>;
>> +};
>> +
>> +&gmac {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&gmac_mii_pins>;
>> + phy-handle = <&phy1>;
>> + phy-mode = "mii";
>> + status = "okay";
>> +};
>> +
>> +&i2c0 {
>> + status = "okay";
>> +
>> + axp209: pmic@34 {
>> + reg = <0x34>;
>> + interrupt-parent = <&nmi_intc>;
>> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>> + };
>> +};
>> +
>> +&gmac_mdio {
>> + phy1: ethernet-phy@1 {
>> + reg = <1>;
>> + };
>> +};
>> +
>> +#include "axp209.dtsi"
>> +
>> +®_dcdc2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1400000>;
>> + regulator-name = "vdd-cpu";
>> +};
>> +
>> +®_dcdc3 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <1000000>;
>> + regulator-max-microvolt = <1400000>;
>> + regulator-name = "vdd-int-dll";
>> +};
>> +
>> +®_ldo1 {
>> + regulator-name = "vdd-rtc";
>> +};
>> +
>> +®_ldo2 {
>> + regulator-always-on;
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3000000>;
>> + regulator-name = "avcc";
>> +};
>> +
>
--
Dipl.-Ing. Ludwig Kormann
In-Circuit GmbH
Boltenhagener Straße 124
01109 Dresden
Germany
Phone: +49 351 42 66 850
Fax: +49 351 42 66 849
Email: ludwig.kormann@in-circuit.de
https://www.in-circuit.de/
Name der Gesellschaft: In-Circuit GmbH
Sitz der Gesellschaft: Dresden
Handelsregister : HRB 23099
Geschäftsführer : Jörg Träger
UST-ID Nr. : DE237550066
_______________________________________________
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 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup
From: Andrew Cooper @ 2023-04-20 9:23 UTC (permalink / raw)
To: Thomas Gleixner, Paul Menzel
Cc: linux-kernel, x86, David Woodhouse, Brian Gerst,
Arjan van de Veen, Paolo Bonzini, Paul McKenney, Tom Lendacky,
Sean Christopherson, Oleksandr Natalenko, Guilherme G. Piccoli,
Piotr Gorski, David Woodhouse, Usama Arif, Jürgen Groß,
Boris Ostrovsky, xen-devel, Russell King, Arnd Bergmann,
linux-arm-kernel, Catalin Marinas, Will Deacon, Guo Ren,
linux-csky, Thomas Bogendoerfer, linux-mips,
James E. J. Bottomley, Helge Deller, linux-parisc, Paul Walmsley,
Palmer Dabbelt, linux-riscv, Mark Rutland, Sabin Rapan
In-Reply-To: <871qkf3qek.ffs@tglx>
On 20/04/2023 9:32 am, Thomas Gleixner wrote:
> On Wed, Apr 19 2023 at 17:21, Andrew Cooper wrote:
>> On 19/04/2023 2:50 pm, Andrew Cooper wrote:
>> For xAPIC, the APIC_ID register is writeable (at least, model
>> specifically), and CPUID is only the value it would have had at reset.
>> So the AP bringup logic can't actually use CPUID reliably.
>>
>> This was changed in x2APIC, which made the x2APIC_ID immutable.
>>
>> I don't see an option other than the AP bringup code query for xAPIC vs
>> x2APIC mode, and either looking at the real APIC_ID register, or falling
>> back to CPUID.
> I'm pondering to simply deny parallel mode if x2APIC is not there.
I'm not sure if that will help much.
Just because x2APIC is there doesn't mean it's in use. There are
several generations of Intel system which have x2APIC but also use the
opt-out bit in ACPI tables. There are some machines which have
mismatched APIC-ness settings in the BIOS->OS handover.
There's very little you can do on the BSP alone to know for certain that
the APs come out of wait-for-SIPI already in x2APIC mode.
One way is the ÆPIC Leak "locked into x2APIC mode" giant security
bodge. If the system really does have a CPU with an APIC ID above 0xfe,
then chances are good that the APs come out consistently...
~Andrew
_______________________________________________
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 1/4] can: m_can: Add hrtimer to generate software interrupt
From: Marc Kleine-Budde @ 2023-04-20 9:37 UTC (permalink / raw)
To: Judith Mendez
Cc: Chandrasekar Ramakrishnan, Wolfgang Grandegger, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Schuyler Patton,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Oliver Hartkopp, linux-arm-kernel,
devicetree, linux-kernel, linux-can, netdev
In-Reply-To: <20230419223323.20384-2-jm@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 5852 bytes --]
On 19.04.2023 17:33:20, Judith Mendez wrote:
> Add an hrtimer to MCAN struct. Each MCAN will have its own
> hrtimer instantiated if there is no hardware interrupt found.
>
> The hrtimer will generate a software interrupt every 1 ms. In
> hrtimer callback, we check if there is a transaction pending by
> reading a register, then process by calling the isr if there is.
>
> Signed-off-by: Judith Mendez <jm@ti.com>
> ---
> drivers/net/can/m_can/m_can.c | 30 ++++++++++++++++++++++++--
> drivers/net/can/m_can/m_can.h | 3 +++
> drivers/net/can/m_can/m_can_platform.c | 13 +++++++++--
> 3 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index a5003435802b..8784bdea300a 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -23,6 +23,7 @@
> #include <linux/pinctrl/consumer.h>
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> +#include <linux/hrtimer.h>
>
> #include "m_can.h"
>
> @@ -1587,6 +1588,11 @@ static int m_can_close(struct net_device *dev)
> if (!cdev->is_peripheral)
> napi_disable(&cdev->napi);
>
> + if (dev->irq < 0) {
> + dev_dbg(cdev->dev, "Disabling the hrtimer\n");
> + hrtimer_cancel(&cdev->hrtimer);
> + }
> +
> m_can_stop(dev);
> m_can_clk_stop(cdev);
> free_irq(dev->irq, dev);
> @@ -1793,6 +1799,18 @@ static netdev_tx_t m_can_start_xmit(struct sk_buff *skb,
> return NETDEV_TX_OK;
> }
>
> +enum hrtimer_restart hrtimer_callback(struct hrtimer *timer)
> +{
> + struct m_can_classdev *cdev =
> + container_of(timer, struct m_can_classdev, hrtimer);
> +
> + m_can_isr(0, cdev->net);
> +
> + hrtimer_forward_now(timer, ms_to_ktime(1));
> +
> + return HRTIMER_RESTART;
> +}
> +
> static int m_can_open(struct net_device *dev)
> {
> struct m_can_classdev *cdev = netdev_priv(dev);
> @@ -1827,13 +1845,21 @@ static int m_can_open(struct net_device *dev)
> }
>
> INIT_WORK(&cdev->tx_work, m_can_tx_work_queue);
> -
> err = request_threaded_irq(dev->irq, NULL, m_can_isr,
> IRQF_ONESHOT,
> dev->name, dev);
> +
nitpick:
Please remove these 2 newline changes.
> } else {
> - err = request_irq(dev->irq, m_can_isr, IRQF_SHARED, dev->name,
> + if (dev->irq > 0) {
Please follow the kernel coding style and use a space not a tab after
the closing ")" of the "if".
> + err = request_irq(dev->irq, m_can_isr, IRQF_SHARED, dev->name,
> dev);
> + }
> +
> + else {
Please use kernel coding style: "} else {"
> + dev_dbg(cdev->dev, "Enabling the hrtimer\n");
> + cdev->hrtimer.function = &hrtimer_callback;
> + hrtimer_start(&cdev->hrtimer, ns_to_ktime(0), HRTIMER_MODE_REL_PINNED);
> + }
I think there's no need to have nested else branches, what about this
approach?
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1831,9 +1831,11 @@ static int m_can_open(struct net_device *dev)
err = request_threaded_irq(dev->irq, NULL, m_can_isr,
IRQF_ONESHOT,
dev->name, dev);
- } else {
+ } else if (dev->irq) {
err = request_irq(dev->irq, m_can_isr, IRQF_SHARED, dev->name,
dev);
+ } else {
+ // polling
}
if (err < 0) {
> }
>
> if (err < 0) {
> diff --git a/drivers/net/can/m_can/m_can.h b/drivers/net/can/m_can/m_can.h
> index a839dc71dc9b..ed046d77fdb9 100644
> --- a/drivers/net/can/m_can/m_can.h
> +++ b/drivers/net/can/m_can/m_can.h
> @@ -28,6 +28,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/slab.h>
> #include <linux/uaccess.h>
> +#include <linux/hrtimer.h>
>
> /* m_can lec values */
> enum m_can_lec_type {
> @@ -93,6 +94,8 @@ struct m_can_classdev {
> int is_peripheral;
>
> struct mram_cfg mcfg[MRAM_CFG_NUM];
> +
> + struct hrtimer hrtimer;
> };
>
> struct m_can_classdev *m_can_class_allocate_dev(struct device *dev, int sizeof_priv);
> diff --git a/drivers/net/can/m_can/m_can_platform.c b/drivers/net/can/m_can/m_can_platform.c
> index 9c1dcf838006..7540db74b7d0 100644
> --- a/drivers/net/can/m_can/m_can_platform.c
> +++ b/drivers/net/can/m_can/m_can_platform.c
> @@ -7,6 +7,7 @@
>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> +#include <linux/hrtimer.h>
>
> #include "m_can.h"
>
> @@ -98,8 +99,16 @@ static int m_can_plat_probe(struct platform_device *pdev)
> addr = devm_platform_ioremap_resource_byname(pdev, "m_can");
> irq = platform_get_irq_byname(pdev, "int0");
> if (IS_ERR(addr) || irq < 0) {
> - ret = -EINVAL;
> - goto probe_fail;
> + if (irq == -EPROBE_DEFER) {
> + ret = -EPROBE_DEFER;
> + goto probe_fail;
> + }
> + if (IS_ERR(addr)) {
> + ret = PTR_ERR(addr);
> + goto probe_fail;
> + }
> + dev_dbg(mcan_class->dev, "Failed to get irq, initialize hrtimer\n");
> + hrtimer_init(&mcan_class->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_PINNED);
Looks better. Please remove the outer "if (IS_ERR(addr) || irq < 0)" and
move the error checking directly after "addr = devm_platform_ioremap_resource_byname()".
What do you think about introducing the "poll-interval" property and
only enable polling if it is set?
> }
>
> /* message ram could be shared */
> --
> 2.17.1
>
>
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 v1 4/5] mtd: rawnand: meson: clear OOB buffer before read
From: Arseniy Krasnov @ 2023-04-20 9:37 UTC (permalink / raw)
To: Liang Yang, Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Jianxin Pan,
Yixun Lan, oxffffaa, kernel, linux-mtd, linux-arm-kernel,
linux-amlogic, linux-kernel, yonghui.yu
In-Reply-To: <5e4b395e-bf9d-0123-a0f2-2b378d950b29@sberdevices.ru>
On 19.04.2023 09:41, Arseniy Krasnov wrote:
>
>
> On 19.04.2023 06:05, Liang Yang wrote:
>> Hi Arseniy,
>>
>> On 2023/4/18 22:57, Arseniy Krasnov wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>>
>>>
>>> On 18.04.2023 16:25, Miquel Raynal wrote:
>>>> Hi Arseniy,
>>>>
>>>>>>> Hello again @Liang @Miquel!
>>>>>>>
>>>>>>> One more question about OOB access, as I can see current driver uses the following
>>>>>>> callbacks:
>>>>>>>
>>>>>>> nand->ecc.write_oob_raw = nand_write_oob_std;
>>>>>>> nand->ecc.write_oob = nand_write_oob_std;
>>>>>>>
>>>>>>>
>>>>>>> Function 'nand_write_oob_std()' writes data to the end of the page. But as I
>>>>>>> can see by dumping 'data_buf' during read, physical layout of each page is the
>>>>>>> following (1KB ECC):
>>>>>>>
>>>>>>> 0x000: [ 1 KB of data ]
>>>>>>> 0x400: [ 2B user data] [ 14B ECC code]
>>>>>>> 0x410: [ 1 KB of data ] (A)
>>>>>>> 0x810: [ 2B user data] [ 14B ECC code]
>>>>>>> 0x820: [ 32B unused ]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> So, after 'nand_write_oob_std()' (let data be sequence from [0x0 ... 0x3f]),
>>>>>>> page will look like this:
>>>>>>>
>>>>>>> 0x000: [ 0xFF ]
>>>>>>> 0x400: [ ........ ]
>>>>>>> 0x7f0: [ 0xFF ]
>>>>>>> 0x800: [ 00 ....................... ]
>>>>>>> 0x830: [ ........................ 3f ]
>>>>>>>
>>>>>>> Here we have two problems:
>>>>>>> 1) Attempt to display raw data by 'nanddump' utility produces a little bit
>>>>>>> invalid output, as driver relies on layout (A) from above. E.g. OOB data
>>>>>>> is at 0x400 and 0x810. Here is an example (attempt to write 0x11 0x22 0x33 0x44):
>>>>>>>
>>>>>>> 0x000007f0: 11 22 ff ff ff ff ff ff ff ff ff ff ff ff ff ff |."..............|
>>>>>>> OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
>>>>>>> OOB Data: 33 44 ff ff ff ff ff ff ff ff ff ff ff ff ff ff |3D..............|
>>>>>>> OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
>>>>>>> OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
>>>>>>>
>>>>>> Hi Arseniy,
>>>>>>
>>>>>> I realized the write_oob_raw() and write_oob() are wrong in meson_nand.c. I suggest both of them should be reworked and follow the format of meson nand controller. i.e. firstly format the data in Layout (A) and then write. reading is firstly reading the data of layout (A) and then compost the layout (B).
>>>>>
>>>>> IIUC after such writing only OOB (e.g. user bytes) according layout (A), hw will also write ECC codes, so
>>>>> it will be impossible to write data to this page later, because we cannot update ECC codes properly for the newly
>>>>> written data (we can't update bits from 0 to 1).
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 2) Attempt to read data in ECC mode will fail, because IIUC page is in dirty
>>>>>>> state (I mean was written at least once) and NAND controller tries to use
>>>>>>> ECC codes at 0x400 and 0x810, which are obviously broken in this case. Thus
>>>>>>
>>>>>> As i said above, write_oob_raw() and write_oob() should be reworked.
>>>>>> i don't know what do you mean page was written at least once. anyway the page should be written once, even just write_oob_raw().
>>>>>
>>>>> Sorry, You mean that after OOB write, we cannot write to the data area (e.g. 0x0 .. 0x810) until page will be erased? For example
>>>>> JFFS2 writes to OOB own markers, then it tries to write to the data area of such page.
>>>
>>> @Liang, I'll describe current test case in details:
>>> 1) I have erased page, I can read it in both raw and ecc modes - no problem (it is full of 0xFF).
>>> 2) I (JFFS2 for example) want to write only OOB - let it be clean markers.
>>> 3) I use raw write to the needed page (please correct me if i'm wrong). Four bytes
>>> at 0x400 and 0x810 are updated. All other bytes still 0xff.
>>> 4) Now, when i'm trying to read this page in ECC mode, I get ECC errors: IIUC this
>>> happens because from controller point of view ECC codes are invalid for current
>>> data (all ECCs are 0xff). Is this behaviour is ok?
>>
>> Yes, it is exactly reported ECC errors.
>
> I see, so if we write OOB (e.g. using raw mode), there is no way to read this page in ECC mode later? And the
> only way to make it readable is to write it in ECC mode, but before this write, we need to read it's
> user's byte (from previous OOB write) in raw mode, put it to info buf (as user's bytes) and write this page. In this
> case NAND controller will generate ECC codes including user's byte and page become readable in ECC mode
> again.
>
>>
>>> 5) Ok, don't care on these ECC errors, let's go further.
>>> 6) I'm going to write same page in ECC mode - how to do it correctly? There is already
>>> 4 OOB bytes, considered to be covered by ECC (but in fact now - ECC area is FFed).
>>
>> If step 4 has excuted "program" command at the page (nand_write_oob_std() does), it can't be written again before erasing the page(block). so we have to read the whole page in the ddr and change the content, erase block, write it again.
>>
>> I don't think Jffs2 has the same steps (1-6) as you said above. are you sure that happes on Jffs2 or just an example?
>
> I just checked JFFS2 mount/umount again, here is what i see:
> 0) First attempt to mount JFFS2.
> 1) It writes OOB to page N (i'm using raw write). It is cleanmarker value 0x85 0x19 0x03 0x20. Mount is done.
> 2) Umount JFFS2. Done.
> 3) Second attempt to mount JFFS2.
> 4) It reads OOB from page N (i'm using raw read). Value is 0x85 0x19 0x03 0x20. Done.
> 5) It reads page N in ECC mode, and i get:
> jffs2: mtd->read(0x100 bytes from N) returned ECC error
> 6) Mount failed.
>
> We already had problem which looks like this on another device. Solution was to use OOB area which is
> not covered by ECC for JFFS2 cleanmarkers.
>
> Thanks, Arseniy
>
@Liang,
Small addition, if i'm trying to implement OOB read/write in ECC mode, then step 5) will success,
but later, JFFS2 tries to write this page (in ECC mode of course), and in this case ECC codes will
be broken, because we can't update them properly without erasing whole page.
Please take a look at this patch from my colleagues:
https://lore.kernel.org/all/20230329114240.378722-1-mmkurbanov@sberdevices.ru
It is related with "We already had problem which looks like this on another device" from above:
in 'f50l1g41lb_ooblayout_free()' we reserve 2 bytes in non-ECC area for bad block markers.
Thanks, Arseniy
>>
>>>
>>> That's why I asked Your opinion about moving OOB data to nonprotected by ECC area (and
>>> leave user's bytes untouched). In this case OOB access is free and not linked with ECC
>>> codes which also covers data.
>>>
>>> Thanks, Arseniy
>>>
>>>>
>>>> A page is written after two steps:
>>>> - loading the data into the NAND chip cache (that's when you use the
>>>> bus)
>>>> - programming the NAND array with the data loaded in cache (that's when
>>>> you wait)
>>>>
>>>> In theory it does not matter where you write in the cache, it's regular
>>>> DRAM, you can make random writes there with the appropriate NAND
>>>> commands. Of course when using embedded hardware ECC engines, the
>>>> controllers usually expect to be fed in a certain way in order to
>>>> produce the ECC bytes and put them at the right location in cache.
>>>>
>>>> And then, when you actually send the "program" command, the NAND cells
>>>> actually get programmed based on what has been loaded in cache.
>>>
>>> Thanks for this details! Very interesting!
>>>
>>>
>>>>
>>>> Thanks,
>>>> Miquèl
>>>
_______________________________________________
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] perf cs-etm: Add support for coresight trace for any range of CPUs
From: James Clark @ 2023-04-20 9:43 UTC (permalink / raw)
To: Ganapatrao Kulkarni
Cc: mathieu.poirier, acme, darren, scott, scclevenger, linux-kernel,
coresight, linux-arm-kernel, mike.leach, suzuki.poulose
In-Reply-To: <20230419172101.78638-1-gankulkarni@os.amperecomputing.com>
On 19/04/2023 18:21, Ganapatrao Kulkarni wrote:
> The current implementation supports coresight trace for a range of
> CPUs, if the first CPU is CPU0.
>
> Adding changes to enable coresight trace for any range of CPUs by
> decoding the first CPU also from the header.
> Later, first CPU id is used instead of CPU0 across the decoder functions.
>
> Signed-off-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
> ---
> .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 4 +-
> .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 3 +-
> tools/perf/util/cs-etm.c | 62 ++++++++++++-------
> 3 files changed, 42 insertions(+), 27 deletions(-)
>
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> index 82a27ab90c8b..41ab299b643b 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
> @@ -724,7 +724,7 @@ cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params,
> }
>
> struct cs_etm_decoder *
> -cs_etm_decoder__new(int decoders, struct cs_etm_decoder_params *d_params,
> +cs_etm_decoder__new(int first_decoder, int decoders, struct cs_etm_decoder_params *d_params,
> struct cs_etm_trace_params t_params[])
> {
> struct cs_etm_decoder *decoder;
> @@ -769,7 +769,7 @@ cs_etm_decoder__new(int decoders, struct cs_etm_decoder_params *d_params,
> /* init raw frame logging if required */
> cs_etm_decoder__init_raw_frame_logging(d_params, decoder);
>
> - for (i = 0; i < decoders; i++) {
> + for (i = first_decoder; i < decoders; i++) {
> ret = cs_etm_decoder__create_etm_decoder(d_params,
> &t_params[i],
> decoder);
> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
> index 92a855fbe5b8..b06193fc75b4 100644
> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
> @@ -90,7 +90,8 @@ int cs_etm_decoder__process_data_block(struct cs_etm_decoder *decoder,
> size_t len, size_t *consumed);
>
> struct cs_etm_decoder *
> -cs_etm_decoder__new(int num_cpu,
> +cs_etm_decoder__new(int first_decoder,
> + int decoders,
> struct cs_etm_decoder_params *d_params,
> struct cs_etm_trace_params t_params[]);
>
> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> index 94e2d02009eb..2619513ae088 100644
> --- a/tools/perf/util/cs-etm.c
> +++ b/tools/perf/util/cs-etm.c
> @@ -55,6 +55,8 @@ struct cs_etm_auxtrace {
> u8 has_virtual_ts; /* Virtual/Kernel timestamps in the trace. */
>
> int num_cpu;
> + int first_cpu;
> + int last_cpu;
> u64 latest_kernel_timestamp;
> u32 auxtrace_type;
> u64 branches_sample_type;
> @@ -638,14 +640,13 @@ static void cs_etm__set_trace_param_ete(struct cs_etm_trace_params *t_params,
> }
>
> static int cs_etm__init_trace_params(struct cs_etm_trace_params *t_params,
> - struct cs_etm_auxtrace *etm,
> - int decoders)
> + struct cs_etm_auxtrace *etm)
> {
> int i;
> u32 etmidr;
> u64 architecture;
>
> - for (i = 0; i < decoders; i++) {
> + for (i = etm->first_cpu; i < etm->last_cpu; i++) {
> architecture = etm->metadata[i][CS_ETM_MAGIC];
>
> switch (architecture) {
> @@ -817,7 +818,7 @@ static void cs_etm__free(struct perf_session *session)
> /* Then the RB tree itself */
> intlist__delete(traceid_list);
>
> - for (i = 0; i < aux->num_cpu; i++)
> + for (i = aux->first_cpu; i < aux->last_cpu; i++)
> zfree(&aux->metadata[i]);
>
> thread__zput(aux->unknown_thread);
> @@ -921,7 +922,8 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
> * Each queue can only contain data from one CPU when unformatted, so only one decoder is
> * needed.
> */
> - int decoders = formatted ? etm->num_cpu : 1;
> + int first_decoder = formatted ? etm->first_cpu : 0;
> + int decoders = first_decoder + (formatted ? etm->num_cpu : 1);
>
> etmq = zalloc(sizeof(*etmq));
> if (!etmq)
> @@ -937,7 +939,7 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
> if (!t_params)
> goto out_free;
>
> - if (cs_etm__init_trace_params(t_params, etm, decoders))
> + if (cs_etm__init_trace_params(t_params, etm))
> goto out_free;
>
> /* Set decoder parameters to decode trace packets */
> @@ -947,8 +949,7 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
> formatted))
> goto out_free;
>
> - etmq->decoder = cs_etm_decoder__new(decoders, &d_params,
> - t_params);
> + etmq->decoder = cs_etm_decoder__new(first_decoder, decoders, &d_params, t_params);
>
> if (!etmq->decoder)
> goto out_free;
> @@ -2959,11 +2960,11 @@ static int cs_etm__queue_aux_records(struct perf_session *session)
> * Loop through the ETMs and complain if we find at least one where ts_source != 1 (virtual
> * timestamps).
> */
> -static bool cs_etm__has_virtual_ts(u64 **metadata, int num_cpu)
> +static bool cs_etm__has_virtual_ts(u64 **metadata, struct cs_etm_auxtrace *etm)
> {
> int j;
>
> - for (j = 0; j < num_cpu; j++) {
> + for (j = etm->first_cpu; j < etm->last_cpu; j++) {
> switch (metadata[j][CS_ETM_MAGIC]) {
> case __perf_cs_etmv4_magic:
> if (HAS_PARAM(j, ETMV4, TS_SOURCE) || metadata[j][CS_ETMV4_TS_SOURCE] != 1)
> @@ -2982,13 +2983,14 @@ static bool cs_etm__has_virtual_ts(u64 **metadata, int num_cpu)
> }
>
> /* map trace ids to correct metadata block, from information in metadata */
> -static int cs_etm__map_trace_ids_metadata(int num_cpu, u64 **metadata)
> +static int cs_etm__map_trace_ids_metadata(struct cs_etm_auxtrace *etm)
> {
> u64 cs_etm_magic;
> + u64 **metadata = etm->metadata;
> u8 trace_chan_id;
> int i, err;
>
> - for (i = 0; i < num_cpu; i++) {
> + for (i = etm->first_cpu; i < etm->last_cpu; i++) {
> cs_etm_magic = metadata[i][CS_ETM_MAGIC];
> switch (cs_etm_magic) {
> case __perf_cs_etmv3_magic:
> @@ -3015,12 +3017,13 @@ static int cs_etm__map_trace_ids_metadata(int num_cpu, u64 **metadata)
> * If we found AUX_HW_ID packets, then set any metadata marked as unused to the
> * unused value to reduce the number of unneeded decoders created.
> */
> -static int cs_etm__clear_unused_trace_ids_metadata(int num_cpu, u64 **metadata)
> +static int cs_etm__clear_unused_trace_ids_metadata(struct cs_etm_auxtrace *etm)
> {
> u64 cs_etm_magic;
> + u64 **metadata = etm->metadata;
> int i;
>
> - for (i = 0; i < num_cpu; i++) {
> + for (i = etm->first_cpu; i < etm->last_cpu; i++) {
> cs_etm_magic = metadata[i][CS_ETM_MAGIC];
> switch (cs_etm_magic) {
> case __perf_cs_etmv3_magic:
> @@ -3049,7 +3052,7 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
> int event_header_size = sizeof(struct perf_event_header);
> int total_size = auxtrace_info->header.size;
> int priv_size = 0;
> - int num_cpu;
> + int num_cpu, first_cpu = 0, last_cpu;
> int err = 0;
> int aux_hw_id_found;
> int i, j;
> @@ -3068,22 +3071,31 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
> /* First the global part */
> ptr = (u64 *) auxtrace_info->priv;
> num_cpu = ptr[CS_PMU_TYPE_CPUS] & 0xffffffff;
> - metadata = zalloc(sizeof(*metadata) * num_cpu);
> +
> + /* Start parsing after the common part of the header */
> + i = CS_HEADER_VERSION_MAX;
> +
> + /*Get CPU id of first event */
> + first_cpu = ptr[i + CS_ETM_CPU];
> + last_cpu = first_cpu + num_cpu;
> +
> + if (first_cpu > cpu__max_cpu().cpu ||
> + last_cpu > cpu__max_cpu().cpu)
> + return -EINVAL;
> +
> + metadata = zalloc(sizeof(*metadata) * last_cpu);
Hi Ganapatrao,
I think I see what the problem is, but I'm wondering if a better fix
would be to further decouple the CPU ID from the index in the array.
With your change it's not clear what happens with sparse recordings, for
example 'perf record -e cs_etm// -C 1,3,5'. And it seems like there is
some wastage in the zalloc here for example if only CPU 256 is traced
then we'd still make 256 decoders but 255 of them would be unused?
I tried to test sparse recordings, but your change doesn't apply to the
latest coresight/next branch. I did notice that 'perf report -D' doesn't
work with them on coresight/next (it just quits), but I couldn't see if
that's fixed with your change.
Would a better fix not be to keep the metadata loops from 0-N and
instead save the CPU ID in cs_etm_decoder_params or the decoder. That
way it would support both sparse and not starting from 0 cases? I think
the code would be better if it's worded like "i < recorded_cpus" rather
than "i < cpu" to make it clear that i isn't actually the CPU ID it's
just an index.
Also a new test for this scenario would probably be a good idea.
Thanks
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/5] MT8195 Acer Tomato - devicetrees Part 3
From: AngeloGioacchino Del Regno @ 2023-04-20 9:44 UTC (permalink / raw)
To: matthias.bgg
Cc: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, kernel,
AngeloGioacchino Del Regno
This series adds support for the WiFi card on PCI-Express,
eDP (internal) and DP (external) displays and adds thermal
configuration for the "extra" thermistors present on Cherry boards.
All Cherry Chromebooks now have working display and wireless
connectivity!
At this point, the only missing component is vcodec decoders, but
that's to be done in mt8195.dtsi, globally, not machine specific.
Please note that in this series the eDP panel was put on aux-bus,
hence this depends on the series introducing support for it [1]
in the mtk-dp driver.
[1]: https://lore.kernel.org/lkml/20230404104800.301150-1-angelogioacchino.delregno@collabora.com/
AngeloGioacchino Del Regno (5):
arm64: dts: mediatek: cherry: Add platform thermal configuration
arm64: dts: mediatek: cherry: Assign dp-intf aliases
arm64: dts: mediatek: cherry: Configure eDP and internal display
arm64: dts: mediatek: cherry: Enable PCI-Express ports for WiFi
arm64: dts: mediatek: cherry-tomato-r1: Enable NVMe PCI-Express port
.../dts/mediatek/mt8195-cherry-tomato-r1.dts | 7 +
.../boot/dts/mediatek/mt8195-cherry.dtsi | 164 ++++++++++++++++++
2 files changed, 171 insertions(+)
--
2.40.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/5] arm64: dts: mediatek: cherry: Add platform thermal configuration
From: AngeloGioacchino Del Regno @ 2023-04-20 9:44 UTC (permalink / raw)
To: matthias.bgg
Cc: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, kernel,
AngeloGioacchino Del Regno
In-Reply-To: <20230420094433.42794-1-angelogioacchino.delregno@collabora.com>
This platform has three auxiliary NTC thermistors, connected to the
SoC's ADC pins. Enable the auxadc in order to be able to read the
ADC values, add a generic-adc-thermal LUT for each and finally assign
them to the SoC's thermal zones.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../boot/dts/mediatek/mt8195-cherry.dtsi | 105 ++++++++++++++++++
1 file changed, 105 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index 8ac80a136c37..0820e9ba3829 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -114,6 +114,77 @@ ppvar_sys: regulator-ppvar-sys {
regulator-boot-on;
};
+ /* Murata NCP03WF104F05RL */
+ tboard_thermistor1: thermal-sensor-t1 {
+ compatible = "generic-adc-thermal";
+ #thermal-sensor-cells = <0>;
+ io-channels = <&auxadc 0>;
+ io-channel-names = "sensor-channel";
+ temperature-lookup-table = < (-10000) 1553
+ (-5000) 1485
+ 0 1406
+ 5000 1317
+ 10000 1219
+ 15000 1115
+ 20000 1007
+ 25000 900
+ 30000 796
+ 35000 697
+ 40000 605
+ 45000 523
+ 50000 449
+ 55000 384
+ 60000 327
+ 65000 279
+ 70000 237
+ 75000 202
+ 80000 172
+ 85000 147
+ 90000 125
+ 95000 107
+ 100000 92
+ 105000 79
+ 110000 68
+ 115000 59
+ 120000 51
+ 125000 44>;
+ };
+
+ tboard_thermistor2: thermal-sensor-t2 {
+ compatible = "generic-adc-thermal";
+ #thermal-sensor-cells = <0>;
+ io-channels = <&auxadc 1>;
+ io-channel-names = "sensor-channel";
+ temperature-lookup-table = < (-10000) 1553
+ (-5000) 1485
+ 0 1406
+ 5000 1317
+ 10000 1219
+ 15000 1115
+ 20000 1007
+ 25000 900
+ 30000 796
+ 35000 697
+ 40000 605
+ 45000 523
+ 50000 449
+ 55000 384
+ 60000 327
+ 65000 279
+ 70000 237
+ 75000 202
+ 80000 172
+ 85000 147
+ 90000 125
+ 95000 107
+ 100000 92
+ 105000 79
+ 110000 68
+ 115000 59
+ 120000 51
+ 125000 44>;
+ };
+
usb_vbus: regulator-5v0-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "usb-vbus";
@@ -260,6 +331,10 @@ &gpu {
mali-supply = <&mt6315_7_vbuck1>;
};
+&auxadc {
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
@@ -1098,6 +1173,36 @@ mt6315_7_vbuck1: vbuck1 {
};
};
+&thermal_zones {
+ soc_area_ntc {
+ polling-delay = <1000>;
+ polling-delay-passive = <250>;
+ thermal-sensors = <&tboard_thermistor1>;
+
+ trips {
+ trip-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ pmic_area_ntc {
+ polling-delay = <1000>;
+ polling-delay-passive = <0>;
+ thermal-sensors = <&tboard_thermistor2>;
+
+ trips {
+ trip-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+};
+
&u3phy0 {
status = "okay";
};
--
2.40.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
* [PATCH 2/5] arm64: dts: mediatek: cherry: Assign dp-intf aliases
From: AngeloGioacchino Del Regno @ 2023-04-20 9:44 UTC (permalink / raw)
To: matthias.bgg
Cc: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, kernel,
AngeloGioacchino Del Regno
In-Reply-To: <20230420094433.42794-1-angelogioacchino.delregno@collabora.com>
On Cherry boards, the IP at 0x1c015000 (dp_intf0) is used as primary
dp-intf, while the other at 0x1c113000 (dp_intf1) is used as secondary:
assign them to dp-intf{0,1} aliases respectively.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index 0820e9ba3829..918380697a9a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -10,6 +10,8 @@
/ {
aliases {
+ dp-intf0 = &dp_intf0;
+ dp-intf1 = &dp_intf1;
i2c0 = &i2c0;
i2c1 = &i2c1;
i2c2 = &i2c2;
--
2.40.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
* [PATCH 3/5] arm64: dts: mediatek: cherry: Configure eDP and internal display
From: AngeloGioacchino Del Regno @ 2023-04-20 9:44 UTC (permalink / raw)
To: matthias.bgg
Cc: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, kernel,
AngeloGioacchino Del Regno
In-Reply-To: <20230420094433.42794-1-angelogioacchino.delregno@collabora.com>
Add the required nodes to enable the DisplayPort interface, connected
to the Embedded DisplayPort port, where we have an internal display.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../boot/dts/mediatek/mt8195-cherry.dtsi | 32 +++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index 918380697a9a..46f1c8091498 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -49,6 +49,18 @@ memory@40000000 {
reg = <0 0x40000000 0 0x80000000>;
};
+ pp3300_disp_x: regulator-pp3300-disp-x {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_disp_x";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ enable-active-high;
+ gpio = <&pio 55 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&panel_fixed_pins>;
+ regulator-always-on;
+ };
+
/* system wide LDO 3.3V power rail */
pp3300_z5: regulator-pp3300-ldo-z5 {
compatible = "regulator-fixed";
@@ -290,6 +302,20 @@ port@1 {
reg = <1>;
edp_out: endpoint {
data-lanes = <0 1 2 3>;
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+ aux-bus {
+ panel {
+ compatible = "edp-panel";
+ power-supply = <&pp3300_disp_x>;
+ backlight = <&backlight_lcd0>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&edp_out>;
+ };
};
};
};
@@ -929,6 +955,12 @@ pins-cs {
};
};
+ panel_fixed_pins: panel-pwr-default-pins {
+ pins-vreg-en {
+ pinmux = <PINMUX_GPIO55__FUNC_GPIO55>;
+ };
+ };
+
pio_default: pio-default-pins {
pins-wifi-enable {
pinmux = <PINMUX_GPIO58__FUNC_GPIO58>;
--
2.40.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
* [PATCH 4/5] arm64: dts: mediatek: cherry: Enable PCI-Express ports for WiFi
From: AngeloGioacchino Del Regno @ 2023-04-20 9:44 UTC (permalink / raw)
To: matthias.bgg
Cc: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, kernel,
AngeloGioacchino Del Regno
In-Reply-To: <20230420094433.42794-1-angelogioacchino.delregno@collabora.com>
On the Cherry platform, a MT7621 WiFi+Bluetooth combo is connected
over PCI-Express (for WiFi) and USB (for BT): enable the PCIe ports
to enable enumerating this chip.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../boot/dts/mediatek/mt8195-cherry.dtsi | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
index 46f1c8091498..9e2bc363c9cd 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
@@ -567,6 +567,13 @@ flash@0 {
};
};
+&pcie1 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_pins_default>;
+};
+
&pio {
mediatek,rsel-resistance-in-si-unit;
pinctrl-names = "default";
@@ -961,6 +968,24 @@ pins-vreg-en {
};
};
+ pcie0_pins_default: pcie0-default-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO19__FUNC_WAKEN>,
+ <PINMUX_GPIO20__FUNC_PERSTN>,
+ <PINMUX_GPIO21__FUNC_CLKREQN>;
+ bias-pull-up;
+ };
+ };
+
+ pcie1_pins_default: pcie1-default-pins {
+ pins-bus {
+ pinmux = <PINMUX_GPIO22__FUNC_PERSTN_1>,
+ <PINMUX_GPIO23__FUNC_CLKREQN_1>,
+ <PINMUX_GPIO24__FUNC_WAKEN_1>;
+ bias-pull-up;
+ };
+ };
+
pio_default: pio-default-pins {
pins-wifi-enable {
pinmux = <PINMUX_GPIO58__FUNC_GPIO58>;
--
2.40.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
* [PATCH 5/5] arm64: dts: mediatek: cherry-tomato-r1: Enable NVMe PCI-Express port
From: AngeloGioacchino Del Regno @ 2023-04-20 9:44 UTC (permalink / raw)
To: matthias.bgg
Cc: robh+dt, krzysztof.kozlowski+dt, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, kernel,
AngeloGioacchino Del Regno
In-Reply-To: <20230420094433.42794-1-angelogioacchino.delregno@collabora.com>
On Tomato rev1 the PCIe0 controller is used for NVMe storage.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts
index 2d5e8f371b6d..11fc83ddf236 100644
--- a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts
@@ -20,6 +20,13 @@ &sound {
model = "mt8195_r1019_5682";
};
+&pcie0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_pins_default>;
+};
+
&ts_10 {
status = "okay";
};
--
2.40.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: SMP enablement on Cortex-R52 (using PSCI ?)
From: Sudeep Holla @ 2023-04-20 9:51 UTC (permalink / raw)
To: Robin Murphy
Cc: Ayan Kumar Halder, mark.rutland, lpieralisi, linux-arm-kernel,
Sudeep Holla, linux-kernel, Vladimir Murzin, Stefano Stabellini
In-Reply-To: <ee7095b4-0bab-d98e-0f7e-633672458b50@arm.com>
On Wed, Apr 19, 2023 at 06:50:26PM +0100, Robin Murphy wrote:
> On 19/04/2023 9:47 am, Sudeep Holla wrote:
> >
> > I will check with the authors if EL3 is a must for PSCI implementation, but
> > IMO it must not be though every aspects described in the spec may not apply
> > when used across EL2/EL1 boundaries especially when EL3 is not implemented
> > in the hardware.
>
> Xen could provide PSCI to EL1 guests using the HVC conduit. However if EL2
> is the highest implemented EL, then Xen is the most privileged software in
> the system - it would have to own the EL2 exception vectors, and it would
> have to own the low-level CPU bringup code. At that point it just wouldn't
> make much sense to HVC *itself* via the PSCI protocol when it could simply
> call the function directly.
>
Agreed, I was focussing to much just on EL2/EL1. I don't know details on how
power management responsibilities are split between Dom0 and hypervisor, but
I am more interested in understanding how cpuidle/suspend would be structured
with the direct function calls.
--
Regards,
Sudeep
_______________________________________________
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 v3 00/13] mm, dma, arm64: Reduce ARCH_KMALLOC_MINALIGN to 8
From: Petr Tesarik @ 2023-04-20 9:52 UTC (permalink / raw)
To: Catalin Marinas, Isaac Manjarres
Cc: Linus Torvalds, Arnd Bergmann, Christoph Hellwig,
Greg Kroah-Hartman, Will Deacon, Marc Zyngier, Andrew Morton,
Herbert Xu, Ard Biesheuvel, Saravana Kannan, Alasdair Kergon,
Daniel Vetter, Joerg Roedel, Mark Brown, Mike Snitzer,
Rafael J. Wysocki, Robin Murphy, linux-mm, iommu,
linux-arm-kernel
In-Reply-To: <ZEARbKMfMS8KdkhJ@arm.com>
On 4/19/2023 6:06 PM, Catalin Marinas wrote:
> On Thu, Mar 16, 2023 at 11:38:47AM -0700, Isaac Manjarres wrote:
>[...]>> Given this, I don't think there's anything blocking this series from
>> being merged. The requirement for SWIOTLB to get to the minimum
>> kmalloc alignment down to 8 bytes shouldn't prevent this series from
>> being merged, as the amount of memory that is allocated for SWIOTLB
>> can be configured through the commandline to minimize the impact of
>> having SWIOTLB memory. Additionally, even if no SWIOTLB is present,
>> this series still offers memory savings on a lot of ARM64 platforms
>> by using the cache line size as the minimum alignment for kmalloc.
>
> Actually, there's some progress on the swiotlb front to allow dynamic
> allocation. I haven't reviewed the series yet (I wasn't aware of it
> until v2) but at a quick look, it limits the dynamic allocation to
> bouncing buffers of at least a page size. Maybe this can be later
> improved for buffers below ARCH_DMA_MINALIGN.
Indeed. My patch allocates dynamic bounce buffers with
dma_direct_alloc_pages() to keep things simple for now, but there is no
real reason against allocating less than a page with another suitable
allocator.
However, I'd be interested what the use case is, so I can assess the
performance impact, which depends on workload, and FYI it may not even
be negative. ;-)
Petr Tesarik
_______________________________________________
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 2/4] dt-bindings: net: can: Make interrupt attributes optional for MCAN
From: Marc Kleine-Budde @ 2023-04-20 10:01 UTC (permalink / raw)
To: Judith Mendez
Cc: Chandrasekar Ramakrishnan, Wolfgang Grandegger, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Schuyler Patton,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Oliver Hartkopp, linux-arm-kernel,
devicetree, linux-kernel, linux-can, netdev
In-Reply-To: <20230419223323.20384-3-jm@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 2728 bytes --]
On 19.04.2023 17:33:21, Judith Mendez wrote:
> For MCAN, remove interrupt and interrupt names from the required
> section.
>
> On AM62x SoC, MCANs on MCU domain do not have hardware interrupt
> routed to A53 Linux, instead they will use software interrupt
> by hrtimer. Make interrupt attributes optional in MCAN node
> by removing from required section.
>
> Signed-off-by: Judith Mendez <jm@ti.com>
This series basically adds polling support to the driver, which is
needed due to HW limitations.
The proposed logic in the driver is to use polling if
platform_get_irq_byname() fails (due to whatever reason) use polling
with a hard-coded interval.
In the kernel I've found the following properties that describe the
polling interval:
bindings/input/input.yaml:
| poll-interval:
| description: Poll interval time in milliseconds.
| $ref: /schemas/types.yaml#/definitions/uint32
bindings/thermal/thermal-zones.yaml:
| polling-delay:
| $ref: /schemas/types.yaml#/definitions/uint32
| description:
| The maximum number of milliseconds to wait between polls when
| checking this thermal zone. Setting this to 0 disables the polling
| timers setup by the thermal framework and assumes that the thermal
| sensors in this zone support interrupts.
bindings/regulator/dlg,da9121.yaml
| dlg,irq-polling-delay-passive-ms:
| minimum: 1000
| maximum: 10000
| description: |
| Specify the polling period, measured in milliseconds, between interrupt status
| update checks. Range 1000-10000 ms.
From my point of view the poll-interval from the input subsystem looks
good. Any objections to use it to specify the polling interval for
IRQ-less devices, too?
> ---
> Documentation/devicetree/bindings/net/can/bosch,m_can.yaml | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
> index 67879aab623b..43f1aa9addc0 100644
> --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
> +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml
> @@ -122,8 +122,6 @@ required:
> - compatible
> - reg
> - reg-names
> - - interrupts
> - - interrupt-names
> - clocks
> - clock-names
> - bosch,mram-cfg
> --
> 2.17.1
>
>
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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] stm: class: Add MIPI OST protocol support
From: Alexander Shishkin @ 2023-04-20 10:02 UTC (permalink / raw)
To: Mao Jinlong, Steven Rostedt, Masami Hiramatsu, Jonathan Corbet,
Maxime Coquelin, Alexandre Torgue, Tingwei Zhang
Cc: Mao Jinlong, linux-kernel, linux-trace-kernel, linux-doc,
linux-stm32, linux-arm-kernel, linux-arm-msm, Yuanfang Zhang,
Tao Zhang, Hao Zhang, alexander.shishkin
In-Reply-To: <20230419141328.37472-1-quic_jinlmao@quicinc.com>
Mao Jinlong <quic_jinlmao@quicinc.com> writes:
> Add MIPI OST(Open System Trace) protocol support for stm to format
> the traces. OST over STP packet consists of Header/Payload/End. In
> header, there will be STARTSIMPLE/VERSION/ENTITY/PROTOCOL. STARTSIMPLE
> is used to signal the beginning of a simplified OST base protocol
> packet.The Entity ID field is a one byte unsigned number that identifies
> the source. FLAG packet is used for END token.
We'd need a better explanation of what OST is, maybe a link to the spec
if one exists.
Another thing that this patch does is adding source identification,
which needs to be described better.
[...]
> +CONFIG_STM_PROTO_OST is for p_ost driver enablement. Once this config
> +is enabled, you can select the p_ost protocol by command below:
> +
> +# mkdir /sys/kernel/config/stp-policy/stm0:p_ost.policy
> +
> +The policy name format is extended like this:
> + <device_name>:<protocol_name>.<policy_name>
> +
> +With coresight-stm device, it will be look like "stm0:p_ost.policy".
The part about protocol selection should probably be in stm.rst
instead.
> +You can check if the protocol is set successfully by:
> +# cat /sys/kernel/config/stp-policy/stm0:p_ost.policy/protocol
> +p_ost
A successful mkdir is technically enough.
> +With MIPI OST protocol driver, the attributes for each protocol node is:
> +# mkdir /sys/kernel/config/stp-policy/stm0:p_ost.policy/default
> +# ls /sys/kernel/config/stp-policy/stm0:p_ost.policy/default
> +channels entity masters
Where's "entity_available"?
> +The entity here is the set the entity that p_ost supports. Currently
> +p_ost supports ftrace and console entity.
> +
> +Get current available entity that p_ost supports:
> +# cat /sys/kernel/config/stp-policy/stm0:p_ost.policy/default/entity_available
> +ftrace console
> +
> +Set entity:
> +# echo 'ftrace' > /sys/kernel/config/stp-policy/stm0:p_ost.policy/default/entity
This is not a very good example, as it will flag everything that goes
through STM as "ftrace", which is probably not what anybody wants.
The bigger question is, why do we need to set the source type (for
which "entity" is not a very good name, btw) in the configfs when
corresponding stm source drivers already carry this information.
There should be a way to propagate the source type from stm source
driver to the protocol driver without relying on the user to set it
correctly.
> +See Documentation/ABI/testing/configfs-stp-policy-p_ost for more details.
> diff --git a/drivers/hwtracing/stm/Kconfig b/drivers/hwtracing/stm/Kconfig
> index eda6b11d40a1..daa4aa09f64d 100644
> --- a/drivers/hwtracing/stm/Kconfig
> +++ b/drivers/hwtracing/stm/Kconfig
> @@ -40,6 +40,20 @@ config STM_PROTO_SYS_T
>
> If you don't know what this is, say N.
>
> +config STM_PROTO_OST
> + tristate "MIPI OST STM framing protocol driver"
> + default CONFIG_STM
> + help
> + This is an implementation of MIPI OST protocol to be used
> + over the STP transport. In addition to the data payload, it
> + also carries additional metadata for entity, better
> + means of trace source identification, etc.
What does "entity" mean here?
[...]
> +#define OST_TOKEN_STARTSIMPLE (0x10)
> +#define OST_VERSION_MIPI1 (0x10 << 8)
Either write them as bits (BIT(12)) or as a hex value (0x1000).
> +/* entity id to identify the source*/
> +#define OST_ENTITY_FTRACE (0x01 << 16)
> +#define OST_ENTITY_CONSOLE (0x02 << 16)
> +
> +#define OST_CONTROL_PROTOCOL (0x0 << 24)
Zero, really? At this point I'm wondering if this code has even been
tested.
[...]
> +static ssize_t
> +ost_t_policy_entity_store(struct config_item *item, const char *page,
> + size_t count)
> +{
> + struct mutex *mutexp = &item->ci_group->cg_subsys->su_mutex;
> + struct ost_policy_node *pn = to_pdrv_policy_node(item);
> + char str[10] = "";
> +
> + mutex_lock(mutexp);
> + if (sscanf(page, "%s", str) != 1)
> + return -EINVAL;
> + mutex_unlock(mutexp);
You forgot to release the mutex in the error path.
Also, why do you need a mutex around sscanf() in the first place?
Also, the sscanf() can overrun str.
> + if (!strcmp(str, str_ost_entity_type[OST_ENTITY_TYPE_FTRACE]))
> + pn->entity_type = OST_ENTITY_TYPE_FTRACE;
> + else if (!strcmp(str, str_ost_entity_type[OST_ENTITY_TYPE_CONSOLE]))
> + pn->entity_type = OST_ENTITY_TYPE_CONSOLE;
Why can't you strcmp() on the page directly?
Also, this is where you do want to hold the mutex.
Also, what if there are more source types?
> + else
> + return -EINVAL;
> + return count;
> +}
> +CONFIGFS_ATTR(ost_t_policy_, entity);
> +
> +static ssize_t ost_t_policy_entity_available_show(struct config_item *item,
> + char *page)
> +{
> + return scnprintf(page, PAGE_SIZE, "%s\n", "ftrace console");
Don't hardcode these.
> +}
> +CONFIGFS_ATTR_RO(ost_t_policy_, entity_available);
> +
> +static struct configfs_attribute *ost_t_policy_attrs[] = {
> + &ost_t_policy_attr_entity,
> + &ost_t_policy_attr_entity_available,
> + NULL,
> +};
> +
> +static ssize_t notrace ost_write(struct stm_data *data,
> + struct stm_output *output, unsigned int chan,
> + const char *buf, size_t count)
> +{
> + unsigned int c = output->channel + chan;
> + unsigned int m = output->master;
> + const unsigned char nil = 0;
> + u32 header = DATA_HEADER;
> + u8 trc_hdr[16];
> + ssize_t sz;
> +
> + struct ost_output *op = output->pdrv_private;
As said above, the stm source driver that calls here already knows its
own source type, there's no need to store it separately.
> +
> + /*
> + * Identify the source by entity type.
> + * If entity type is not set, return error value.
> + */
> + if (op->node.entity_type == OST_ENTITY_TYPE_FTRACE) {
> + header |= OST_ENTITY_FTRACE;
> + } else if (op->node.entity_type == OST_ENTITY_TYPE_CONSOLE) {
> + header |= OST_ENTITY_CONSOLE;
> + } else {
> + pr_debug("p_ost: Entity must be set for trace data.");
You forgot a newline.
Also, this message seems to be quite useless: it's either a nop or a
dmesg storm. In general, it's a bad idea to printk() in the write
callback.
> + return -EINVAL;
> + }
> +
> + /*
> + * STP framing rules for OST frames:
> + * * the first packet of the OST frame is marked;
> + * * the last packet is a FLAG with timestamped tag.
> + */
> + /* Message layout: HEADER / DATA / TAIL */
> + /* HEADER */
> + sz = data->packet(data, m, c, STP_PACKET_DATA, STP_PACKET_MARKED,
> + 4, (u8 *)&header);
> + if (sz <= 0)
> + return sz;
> +
> + /* DATA */
> + *(u16 *)(trc_hdr) = STM_MAKE_VERSION(0, 4);
> + *(u16 *)(trc_hdr + 2) = STM_HEADER_MAGIC;
> + *(u32 *)(trc_hdr + 4) = raw_smp_processor_id();
> + *(u64 *)(trc_hdr + 8) = task_tgid_nr(get_current());
What's the value in exporting PIDs when there are PID namespaces? How is
this useful? Also, neither console nor ftrace are required to come in a
task context.
I already asked in the previous version, why is trc_hdr not a struct?
There also used to be a timestamp field in trc_hdr, what happened to it?
Regards,
--
Alex
_______________________________________________
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] perf cs-etm: Add support for coresight trace for any range of CPUs
From: James Clark @ 2023-04-20 10:14 UTC (permalink / raw)
To: Ganapatrao Kulkarni
Cc: mathieu.poirier, acme, darren, scott, scclevenger, linux-kernel,
coresight, linux-arm-kernel, mike.leach
In-Reply-To: <d758c5e2-aa32-d829-35ee-a685bdb56f75@arm.com>
On 20/04/2023 10:43, James Clark wrote:
>
>
> On 19/04/2023 18:21, Ganapatrao Kulkarni wrote:
>> The current implementation supports coresight trace for a range of
>> CPUs, if the first CPU is CPU0.
>>
>> Adding changes to enable coresight trace for any range of CPUs by
>> decoding the first CPU also from the header.
>> Later, first CPU id is used instead of CPU0 across the decoder functions.
>>
>> Signed-off-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
>> ---
>> .../perf/util/cs-etm-decoder/cs-etm-decoder.c | 4 +-
>> .../perf/util/cs-etm-decoder/cs-etm-decoder.h | 3 +-
>> tools/perf/util/cs-etm.c | 62 ++++++++++++-------
>> 3 files changed, 42 insertions(+), 27 deletions(-)
>>
>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> index 82a27ab90c8b..41ab299b643b 100644
>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> @@ -724,7 +724,7 @@ cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params,
>> }
>>
>> struct cs_etm_decoder *
>> -cs_etm_decoder__new(int decoders, struct cs_etm_decoder_params *d_params,
>> +cs_etm_decoder__new(int first_decoder, int decoders, struct cs_etm_decoder_params *d_params,
>> struct cs_etm_trace_params t_params[])
>> {
>> struct cs_etm_decoder *decoder;
>> @@ -769,7 +769,7 @@ cs_etm_decoder__new(int decoders, struct cs_etm_decoder_params *d_params,
>> /* init raw frame logging if required */
>> cs_etm_decoder__init_raw_frame_logging(d_params, decoder);
>>
>> - for (i = 0; i < decoders; i++) {
>> + for (i = first_decoder; i < decoders; i++) {
>> ret = cs_etm_decoder__create_etm_decoder(d_params,
>> &t_params[i],
>> decoder);
>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> index 92a855fbe5b8..b06193fc75b4 100644
>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> @@ -90,7 +90,8 @@ int cs_etm_decoder__process_data_block(struct cs_etm_decoder *decoder,
>> size_t len, size_t *consumed);
>>
>> struct cs_etm_decoder *
>> -cs_etm_decoder__new(int num_cpu,
>> +cs_etm_decoder__new(int first_decoder,
>> + int decoders,
>> struct cs_etm_decoder_params *d_params,
>> struct cs_etm_trace_params t_params[]);
>>
>> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>> index 94e2d02009eb..2619513ae088 100644
>> --- a/tools/perf/util/cs-etm.c
>> +++ b/tools/perf/util/cs-etm.c
>> @@ -55,6 +55,8 @@ struct cs_etm_auxtrace {
>> u8 has_virtual_ts; /* Virtual/Kernel timestamps in the trace. */
>>
>> int num_cpu;
>> + int first_cpu;
>> + int last_cpu;
>> u64 latest_kernel_timestamp;
>> u32 auxtrace_type;
>> u64 branches_sample_type;
>> @@ -638,14 +640,13 @@ static void cs_etm__set_trace_param_ete(struct cs_etm_trace_params *t_params,
>> }
>>
>> static int cs_etm__init_trace_params(struct cs_etm_trace_params *t_params,
>> - struct cs_etm_auxtrace *etm,
>> - int decoders)
>> + struct cs_etm_auxtrace *etm)
>> {
>> int i;
>> u32 etmidr;
>> u64 architecture;
>>
>> - for (i = 0; i < decoders; i++) {
>> + for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>> architecture = etm->metadata[i][CS_ETM_MAGIC];
>>
>> switch (architecture) {
>> @@ -817,7 +818,7 @@ static void cs_etm__free(struct perf_session *session)
>> /* Then the RB tree itself */
>> intlist__delete(traceid_list);
>>
>> - for (i = 0; i < aux->num_cpu; i++)
>> + for (i = aux->first_cpu; i < aux->last_cpu; i++)
>> zfree(&aux->metadata[i]);
>>
>> thread__zput(aux->unknown_thread);
>> @@ -921,7 +922,8 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>> * Each queue can only contain data from one CPU when unformatted, so only one decoder is
>> * needed.
>> */
>> - int decoders = formatted ? etm->num_cpu : 1;
>> + int first_decoder = formatted ? etm->first_cpu : 0;
>> + int decoders = first_decoder + (formatted ? etm->num_cpu : 1);
>>
>> etmq = zalloc(sizeof(*etmq));
>> if (!etmq)
>> @@ -937,7 +939,7 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>> if (!t_params)
>> goto out_free;
>>
>> - if (cs_etm__init_trace_params(t_params, etm, decoders))
>> + if (cs_etm__init_trace_params(t_params, etm))
>> goto out_free;
>>
>> /* Set decoder parameters to decode trace packets */
>> @@ -947,8 +949,7 @@ static struct cs_etm_queue *cs_etm__alloc_queue(struct cs_etm_auxtrace *etm,
>> formatted))
>> goto out_free;
>>
>> - etmq->decoder = cs_etm_decoder__new(decoders, &d_params,
>> - t_params);
>> + etmq->decoder = cs_etm_decoder__new(first_decoder, decoders, &d_params, t_params);
>>
>> if (!etmq->decoder)
>> goto out_free;
>> @@ -2959,11 +2960,11 @@ static int cs_etm__queue_aux_records(struct perf_session *session)
>> * Loop through the ETMs and complain if we find at least one where ts_source != 1 (virtual
>> * timestamps).
>> */
>> -static bool cs_etm__has_virtual_ts(u64 **metadata, int num_cpu)
>> +static bool cs_etm__has_virtual_ts(u64 **metadata, struct cs_etm_auxtrace *etm)
>> {
>> int j;
>>
>> - for (j = 0; j < num_cpu; j++) {
>> + for (j = etm->first_cpu; j < etm->last_cpu; j++) {
>> switch (metadata[j][CS_ETM_MAGIC]) {
>> case __perf_cs_etmv4_magic:
>> if (HAS_PARAM(j, ETMV4, TS_SOURCE) || metadata[j][CS_ETMV4_TS_SOURCE] != 1)
>> @@ -2982,13 +2983,14 @@ static bool cs_etm__has_virtual_ts(u64 **metadata, int num_cpu)
>> }
>>
>> /* map trace ids to correct metadata block, from information in metadata */
>> -static int cs_etm__map_trace_ids_metadata(int num_cpu, u64 **metadata)
>> +static int cs_etm__map_trace_ids_metadata(struct cs_etm_auxtrace *etm)
>> {
>> u64 cs_etm_magic;
>> + u64 **metadata = etm->metadata;
>> u8 trace_chan_id;
>> int i, err;
>>
>> - for (i = 0; i < num_cpu; i++) {
>> + for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>> cs_etm_magic = metadata[i][CS_ETM_MAGIC];
>> switch (cs_etm_magic) {
>> case __perf_cs_etmv3_magic:
>> @@ -3015,12 +3017,13 @@ static int cs_etm__map_trace_ids_metadata(int num_cpu, u64 **metadata)
>> * If we found AUX_HW_ID packets, then set any metadata marked as unused to the
>> * unused value to reduce the number of unneeded decoders created.
>> */
>> -static int cs_etm__clear_unused_trace_ids_metadata(int num_cpu, u64 **metadata)
>> +static int cs_etm__clear_unused_trace_ids_metadata(struct cs_etm_auxtrace *etm)
>> {
>> u64 cs_etm_magic;
>> + u64 **metadata = etm->metadata;
>> int i;
>>
>> - for (i = 0; i < num_cpu; i++) {
>> + for (i = etm->first_cpu; i < etm->last_cpu; i++) {
>> cs_etm_magic = metadata[i][CS_ETM_MAGIC];
>> switch (cs_etm_magic) {
>> case __perf_cs_etmv3_magic:
>> @@ -3049,7 +3052,7 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
>> int event_header_size = sizeof(struct perf_event_header);
>> int total_size = auxtrace_info->header.size;
>> int priv_size = 0;
>> - int num_cpu;
>> + int num_cpu, first_cpu = 0, last_cpu;
>> int err = 0;
>> int aux_hw_id_found;
>> int i, j;
>> @@ -3068,22 +3071,31 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
>> /* First the global part */
>> ptr = (u64 *) auxtrace_info->priv;
>> num_cpu = ptr[CS_PMU_TYPE_CPUS] & 0xffffffff;
>> - metadata = zalloc(sizeof(*metadata) * num_cpu);
>> +
>> + /* Start parsing after the common part of the header */
>> + i = CS_HEADER_VERSION_MAX;
>> +
>> + /*Get CPU id of first event */
>> + first_cpu = ptr[i + CS_ETM_CPU];
>> + last_cpu = first_cpu + num_cpu;
>> +
>> + if (first_cpu > cpu__max_cpu().cpu ||
>> + last_cpu > cpu__max_cpu().cpu)
>> + return -EINVAL;
>> +
>> + metadata = zalloc(sizeof(*metadata) * last_cpu);
>
> Hi Ganapatrao,
>
> I think I see what the problem is, but I'm wondering if a better fix
> would be to further decouple the CPU ID from the index in the array.
>
> With your change it's not clear what happens with sparse recordings, for
> example 'perf record -e cs_etm// -C 1,3,5'. And it seems like there is
> some wastage in the zalloc here for example if only CPU 256 is traced
> then we'd still make 256 decoders but 255 of them would be unused?
>
> I tried to test sparse recordings, but your change doesn't apply to the
> latest coresight/next branch. I did notice that 'perf report -D' doesn't
> work with them on coresight/next (it just quits), but I couldn't see if
> that's fixed with your change.
>
> Would a better fix not be to keep the metadata loops from 0-N and
> instead save the CPU ID in cs_etm_decoder_params or the decoder. That
> way it would support both sparse and not starting from 0 cases? I think
> the code would be better if it's worded like "i < recorded_cpus" rather
> than "i < cpu" to make it clear that i isn't actually the CPU ID it's
> just an index.
>
> Also a new test for this scenario would probably be a good idea.
>
> Thanks
> James
>
BTW for the test, I'm currently working on something where I've added
something like this to test_arm_coresight.sh:
arm_cs_etm_basic_test() {
echo "Recording trace with $@"
perf record -o ${perfdata} "$@" -- ls > /dev/null 2>&1
perf_script_branch_samples ls &&
perf_report_branch_samples ls &&
perf_report_instruction_samples ls
err=$?
arm_cs_report "CoreSight basic testing with %@" $err
}
# Test all combinations of per-thread, system-wide and normal mode with
# and without timestamps
arm_cs_etm_basic_test -e cs_etm/timestamp=0/ --per-thread
arm_cs_etm_basic_test -e cs_etm/timestamp=1/ --per-thread
arm_cs_etm_basic_test -e cs_etm/timestamp=0/ -a
arm_cs_etm_basic_test -e cs_etm/timestamp=1/ -a
arm_cs_etm_basic_test -e cs_etm/timestamp=0/
arm_cs_etm_basic_test -e cs_etm/timestamp=1/
I think you should be able to add this to cover your cases as well:
# Test non-zero indexed and sparse CPU lists
arm_cs_etm_basic_test -e cs_etm// -C 1,2
arm_cs_etm_basic_test -e cs_etm// -C 0,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 v3 1/2] dt-bindings: arm: sunxi: add ICnova A20 ADB4006 binding
From: Ludwig Kormann @ 2023-04-20 10:24 UTC (permalink / raw)
To: samuel, jernej.skrabec, wens, robh+dt, krzysztof.kozlowski+dt,
andre.przywara
Cc: linux-arm-kernel, devicetree, linux-sunxi, linux-kernel
In-Reply-To: <20230420102409.1394618-1-ludwig.kormann@in-circuit.de>
Document board compatible names for In-Circuit ICnova A20 ADB4006
development board.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Ludwig Kormann <ludwig.kormann@in-circuit.de>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 013821f4a7b8..ee8fdd2da869 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -305,6 +305,12 @@ properties:
- const: allwinner,i12-tvbox
- const: allwinner,sun7i-a20
+ - description: ICnova A20 ADB4006
+ items:
+ - const: incircuit,icnova-a20-adb4006
+ - const: incircuit,icnova-a20
+ - const: allwinner,sun7i-a20
+
- description: ICNova A20 SWAC
items:
- const: incircuit,icnova-a20-swac
--
2.30.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 v3 0/2] arm: dts: sunxi: Add ICnova A20 ADB4006 board support
From: Ludwig Kormann @ 2023-04-20 10:24 UTC (permalink / raw)
To: samuel, jernej.skrabec, wens, robh+dt, krzysztof.kozlowski+dt,
andre.przywara
Cc: linux-arm-kernel, devicetree, linux-sunxi, linux-kernel
Add board support for ICnova A20 SomPi compute module on
ICnova ADB4006 development board.
v3:
- drop stray blank lines at end of files
- separate patch for bindings
- update licensing to "GPL-2.0 OR MIT"
- fix typo: ICNova -> ICnova
v2:
- use short licensing header
- remove deprecated elements from led nodes
- disable csi power supply
- add missing pins in usbphy node
- split dts into SoM dtsi and carrier board dts
v1 of this patch was sent to the uboot mailing list [1].
[1] https://lists.denx.de/pipermail/u-boot/2023-April/514605.html
Ludwig Kormann (2):
dt-bindings: arm: sunxi: add ICnova A20 ADB4006 binding
arm: dts: sunxi: Add ICnova A20 ADB4006 board
.../devicetree/bindings/arm/sunxi.yaml | 6 +
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++++++++++++++++++
arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi | 62 ++++++++
4 files changed, 206 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
--
2.30.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 v3 2/2] arm: dts: sunxi: Add ICnova A20 ADB4006 board
From: Ludwig Kormann @ 2023-04-20 10:24 UTC (permalink / raw)
To: samuel, jernej.skrabec, wens, robh+dt, krzysztof.kozlowski+dt,
andre.przywara
Cc: linux-arm-kernel, devicetree, linux-sunxi, linux-kernel
In-Reply-To: <20230420102409.1394618-1-ludwig.kormann@in-circuit.de>
Add board support for ICnova A20 SomPi compute module on
ICnova ADB4006 development board.
Specification:
SoM
- Processor: Allwinner A20 Cortex-A7 Dual Core at 1GHz
- 512MB DDR3 RAM
- Fast Ethernet (Phy: Realtek RTL8201CP)
ADB4006
- I2C
- 2x USB 2.0
- 1x Fast Ethernet port
- 1x SATA
- 2x buttons (PWRON, Boot)
- 2x LEDS
- serial console
- HDMI
- µSD-Card slot
- Audio Line-In / Line-Out
- GPIO pinheaders
https://wiki.in-circuit.de/index.php5?title=ICnova_ADB4006
https://wiki.in-circuit.de/index.php5?title=ICnova_A20_SODIMM
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Ludwig Kormann <ludwig.kormann@in-circuit.de>
---
arch/arm/boot/dts/Makefile | 1 +
.../boot/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++++++++++++++++++
arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi | 62 ++++++++
3 files changed, 200 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
create mode 100644 arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 3cc32722c394..b6b408417261 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1321,6 +1321,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-hummingbird.dtb \
sun7i-a20-itead-ibox.dtb \
sun7i-a20-i12-tvbox.dtb \
+ sun7i-a20-icnova-a20-adb4006.dtb \
sun7i-a20-icnova-swac.dtb \
sun7i-a20-lamobo-r1.dtb \
sun7i-a20-linutronix-testbox-v2.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
new file mode 100644
index 000000000000..577ead1d02a0
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20-adb4006.dts
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (C) 2023 In-Circuit GmbH
+
+/dts-v1/;
+
+#include "sun7i-a20-icnova-a20.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
+
+/ {
+ model = "In-Circuit ICnova A20 ADB4006";
+ compatible = "incircuit,icnova-a20-adb4006", "incircuit,icnova-a20",
+ "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ function = LED_FUNCTION_POWER;
+ color = <LED_COLOR_ID_YELLOW>;
+ gpios = <&pio 7 21 GPIO_ACTIVE_HIGH>; /* PH21 */
+ default-state = "on";
+ };
+
+ led-1 {
+ function = LED_FUNCTION_HEARTBEAT;
+ color = <LED_COLOR_ID_RED>;
+ gpios = <&pio 7 20 GPIO_ACTIVE_HIGH>; /* PH20 */
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&ahci {
+ target-supply = <®_ahci_5v>;
+ status = "okay";
+};
+
+&codec {
+ status = "okay";
+};
+
+&de {
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 7 1 GPIO_ACTIVE_LOW>; /* PH1 */
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&otg_sram {
+ status = "okay";
+};
+
+®_ahci_5v {
+ status = "okay";
+};
+
+&ac_power_supply {
+ status = "okay";
+};
+
+®_usb1_vbus {
+ status = "okay";
+};
+
+®_usb2_vbus {
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pb_pins>;
+ status = "okay";
+};
+
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ usb0_id_det-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
+ usb0_vbus_det-gpios = <&pio 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
+ usb1_vbus-supply = <®_usb1_vbus>;
+ usb2_vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi b/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
new file mode 100644
index 000000000000..46616c6bc899
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-icnova-a20.dtsi
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+// Copyright (C) 2023 In-Circuit GmbH
+
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+&cpu0 {
+ cpu-supply = <®_dcdc2>;
+};
+
+&gmac {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_mii_pins>;
+ phy-handle = <&phy1>;
+ phy-mode = "mii";
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic@34 {
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
+
+&gmac_mdio {
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
+#include "axp209.dtsi"
+
+®_dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+ regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "avcc";
+};
--
2.30.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 v4 3/4] media: imx: imx7-media-csi: Relax width constraints for non-8bpp formats
From: Laurent Pinchart @ 2023-04-20 10:33 UTC (permalink / raw)
To: Alexander Stein
Cc: Rui Miguel Silva, Mauro Carvalho Chehab, Shawn Guo, Sascha Hauer,
Fabio Estevam, Pengutronix Kernel Team, NXP Linux Team,
linux-media, linux-arm-kernel
In-Reply-To: <20230419070712.1422335-4-alexander.stein@ew.tq-group.com>
Hi Alexander,
Thank you for the patch.
On Wed, Apr 19, 2023 at 09:07:11AM +0200, Alexander Stein wrote:
> The driver unconditionally aligns the image width to multiples of 8
> pixels. The real alignment constraint is 8 bytes, as indicated by the
> CSI_IMAG_PARA.IMAGE_WIDTH documentation that calls for 8 pixel alignment
> for 8bpp formats and 4 pixel alignment for other formats.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Changes in v4:
> * Improve commit message
> * Simplify walign calculation
> * Remove comment on hardware alignment constraints
>
> drivers/media/platform/nxp/imx7-media-csi.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/nxp/imx7-media-csi.c b/drivers/media/platform/nxp/imx7-media-csi.c
> index 1315f5743b76f..e6abbfbc5c129 100644
> --- a/drivers/media/platform/nxp/imx7-media-csi.c
> +++ b/drivers/media/platform/nxp/imx7-media-csi.c
> @@ -1146,6 +1146,7 @@ __imx7_csi_video_try_fmt(struct v4l2_pix_format *pixfmt,
> struct v4l2_rect *compose)
> {
> const struct imx7_csi_pixfmt *cc;
> + u32 walign;
>
> if (compose) {
> compose->width = pixfmt->width;
> @@ -1163,12 +1164,13 @@ __imx7_csi_video_try_fmt(struct v4l2_pix_format *pixfmt,
> }
>
> /*
> - * Round up width for minimum burst size.
> + * The width alignment is 8 bytes as indicated by the
> + * CSI_IMAG_PARA.IMAGE_WIDTH documentation. Convert it to pixels.
> *
> - * TODO: Implement configurable stride support, and check what the real
> - * hardware alignment constraint on the width is.
> + * TODO: Implement configurable stride support.
> */
> - v4l_bound_align_image(&pixfmt->width, 1, 0xffff, 8,
> + walign = 8 * 8 / cc->bpp;
> + v4l_bound_align_image(&pixfmt->width, 1, 0xffff, walign,
> &pixfmt->height, 1, 0xffff, 1, 0);
>
> pixfmt->bytesperline = pixfmt->width * cc->bpp / 8;
--
Regards,
Laurent Pinchart
_______________________________________________
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: mfd: stm32: Remove unnecessary blank lines
From: Lee Jones @ 2023-04-20 10:36 UTC (permalink / raw)
To: Patrick Delaunay
Cc: Alexandre TORGUE, Rob Herring, Krzysztof Kozlowski,
Maxime Coquelin, devicetree, linux-arm-kernel, linux-kernel,
linux-stm32
In-Reply-To: <20230417181342.v2.1.I483a676579cc7e3ac07e1db649091553743fecc8@changeid>
On Mon, 17 Apr 2023, Patrick Delaunay wrote:
> Remove double blank line.
>
> Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
> ---
>
> Changes in v2:
> - update commit title and commit message to reflect what the change is
> V1="dt-bindings: mfd: stm32: Fix STM32F4 DT include file"
>
> include/dt-bindings/mfd/stm32f4-rcc.h | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks
--
Lee Jones [李琼斯]
_______________________________________________
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: mfd: stm32: Remove unnecessary blank lines
From: Lee Jones @ 2023-04-20 10:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Patrick Delaunay, Alexandre TORGUE, Rob Herring,
Krzysztof Kozlowski, Maxime Coquelin, devicetree,
linux-arm-kernel, linux-kernel, linux-stm32
In-Reply-To: <fde49fb8-c337-3a6b-811e-b9d7c3620393@linaro.org>
On Tue, 18 Apr 2023, Krzysztof Kozlowski wrote:
> On 17/04/2023 18:14, Patrick Delaunay wrote:
> > Remove double blank line.
> >
> > Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
> > ---
> >
> > Changes in v2:
> > - update commit title and commit message to reflect what the change is
> > V1="dt-bindings: mfd: stm32: Fix STM32F4 DT include fil
>
> More than one file has the same issue. This is quite a churn to handle
> such patch one by one. Please fix all of them or just skip, as it is
> harmless.
It was easier to just apply it this time.
--
Lee Jones [李琼斯]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V4 0/4] watchdog: xilinx_wwdt: Add Versal watchdog support
From: Srinivas Neeli @ 2023-04-20 10:42 UTC (permalink / raw)
To: shubhrajyoti.datta, michal.simek, srinivas.goud, wim, linux,
robh+dt, krzysztof.kozlowski+dt
Cc: srinivas.neeli, linux-watchdog, devicetree, linux-kernel,
linux-arm-kernel, git, git, neelisrinivas18
This patch series does
-Adds dt-bindings for versal watchdog driver.
-Adds support for versal watchdog driver.
-Adds fragment page for xilinx watchdog drivers.
There was a series[1] sent earlier to add versal watchdog support using
pretimeout. In review it was discouraged to use pretimeout for open and
close window . This series is a new implementation of versal watchdog.
Srinivas Neeli (4):
MAINTAINERS: Add fragment for Xilinx watchdog driver
dt-bindings: watchdog: xlnx,versal-wwdt: Add versal watchdog
watchdog: xilinx_wwdt: Add Versal window watchdog support
MAINTAINERS: Add support for Xilinx versal watchdog
.../bindings/watchdog/xlnx,versal-wwdt.yaml | 50 +++++
MAINTAINERS | 10 +
drivers/watchdog/Kconfig | 18 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/xilinx_wwdt.c | 201 ++++++++++++++++++
5 files changed, 280 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
create mode 100644 drivers/watchdog/xilinx_wwdt.c
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V4 1/4] MAINTAINERS: Add fragment for Xilinx watchdog driver
From: Srinivas Neeli @ 2023-04-20 10:42 UTC (permalink / raw)
To: shubhrajyoti.datta, michal.simek, srinivas.goud, wim, linux,
robh+dt, krzysztof.kozlowski+dt
Cc: srinivas.neeli, linux-watchdog, devicetree, linux-kernel,
linux-arm-kernel, git, git, neelisrinivas18
In-Reply-To: <20230420104231.2243079-1-srinivas.neeli@amd.com>
Added entry for Xilinx xps-timebase watchdog driver.
Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
---
Changes in V4:
- Updated patch with reviewed tag
Changes in V3:
-None
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index eddbc48c61e9..327901c9f1d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23143,6 +23143,14 @@ F: Documentation/devicetree/bindings/media/xilinx/
F: drivers/media/platform/xilinx/
F: include/uapi/linux/xilinx-v4l2-controls.h
+XILINX WATCHDOG DRIVER
+M: Srinivas Neeli <srinivas.neeli@amd.com>
+R: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
+R: Michal Simek <michal.simek@amd.com>
+S: Maintained
+F: Documentation/devicetree/bindings/watchdog/xlnx,xps-timebase-wdt.yaml
+F: drivers/watchdog/of_xilinx_wdt.c
+
XILINX XDMA DRIVER
M: Lizhi Hou <lizhi.hou@amd.com>
M: Brian Xu <brian.xu@amd.com>
--
2.25.1
_______________________________________________
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 V4 2/4] dt-bindings: watchdog: xlnx,versal-wwdt: Add versal watchdog
From: Srinivas Neeli @ 2023-04-20 10:42 UTC (permalink / raw)
To: shubhrajyoti.datta, michal.simek, srinivas.goud, wim, linux,
robh+dt, krzysztof.kozlowski+dt
Cc: srinivas.neeli, linux-watchdog, devicetree, linux-kernel,
linux-arm-kernel, git, git, neelisrinivas18
In-Reply-To: <20230420104231.2243079-1-srinivas.neeli@amd.com>
Versal watchdog IP uses window watchdog mode. Window watchdog
timer(WWDT) contains closed(first) and open(second) window with
32 bit width. Write to the watchdog timer within predefined window
periods of time. This means a period that is not too soon and
a period that is not too late.
Add devicetree bindings for versal window watchdog device.
Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
---
Changes in V4:
- Updated commit subject(removed redundant "bindings").
- Updated commit descriptioni(removed "this patch").
- Updated watchdog.yaml reference to local.
Changes in V3:
- Removed xlnx,close_percent property.
Changes in V2:
- Added watchdog ref
- Removed timeout-sec property
- Used 4 spaces for example indentation.
---
.../bindings/watchdog/xlnx,versal-wwdt.yaml | 50 +++++++++++++++++++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
new file mode 100644
index 000000000000..14b069599740
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/xlnx,versal-wwdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/xlnx,versal-wwdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xilinx Versal window watchdog timer controller
+
+maintainers:
+ - Neeli Srinivas <srinivas.neeli@amd.com>
+
+description:
+ Versal watchdog intellectual property uses window watchdog mode.
+ Window watchdog timer(WWDT) contains closed(first) and open(second)
+ window with 32 bit width. Write to the watchdog timer within
+ predefined window periods of time. This means a period that is not
+ too soon and a period that is not too late. The WWDT has to be
+ restarted within the open window time. If software tries to restart
+ WWDT outside of the open window time period, it generates a reset.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ enum:
+ - xlnx,versal-wwdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ watchdog@fd4d0000 {
+ compatible = "xlnx,versal-wwdt";
+ reg = <0xfd4d0000 0x10000>;
+ clocks = <&clock25>;
+ timeout-sec = <30>;
+ };
+...
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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