* Re: [RFC][PATCH 0/2] Amlogic T7 (A113D2) Clock Driver
From: Lucas Tanure @ 2024-04-03 8:12 UTC (permalink / raw)
To: Xianwei Zhao
Cc: Yu Tu, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stephen Boyd, Michael Turquette, linux-arm-kernel,
linux-amlogic, devicetree, linux-kernel, linux-clk
In-Reply-To: <1e6ce146-ebf6-4200-be8b-a4ec78675d40@amlogic.com>
On Wed, Apr 3, 2024 at 7:44 AM Xianwei Zhao <xianwei.zhao@amlogic.com> wrote:
>
> Hi Lucas,
> As we are preparing the T7 clock patchset, we would like to your
> purpose and plan of this RFC patches. Are you going to submit these
> patches at last?
Hi Xianwei,
I made some progress, and now the SD card controller probes but fails
to read blocks from the SD card. I do think my port of the clock
driver is okay, but I will not send my clock driver until the SD card
fully works, so I am sure the clocking driver is tested.
But if you have something already done, please send it, and I will
test and review it from my side.
Any help with the sdcard controller is also much appreciated.
Thanks
Lucas
> On 2024/3/18 19:43, Lucas Tanure wrote:
> > [ EXTERNAL EMAIL ]
> >
> > I am trying to port the T7 clock driver from Khadas 5.4 kernel for Vim4
> > to mainline, but I am encountering some issues in the path.
> >
> > The kernel panics at clk_mux_val_to_index, but I believe that all the
> > needed clocks are registered.
> >
> > If anyone from Amlogic or the community could help me understand what
> > my driver is missing, that would be great.
> > I will continue to try to figure out, but it has been some weeks
> > without progress =/.
> >
> > Lucas Tanure (2):
> > clk: meson: T7: add support for Amlogic T7 SoC PLL clock driver
> > arm64: dts: amlogic: t7: SDCard, Ethernet and Clocking
> >
> > .../amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 66 +
> > arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 189 +
> > drivers/clk/meson/Kconfig | 25 +
> > drivers/clk/meson/Makefile | 2 +
> > drivers/clk/meson/t7-peripherals.c | 6368 +++++++++++++++++
> > drivers/clk/meson/t7-peripherals.h | 131 +
> > drivers/clk/meson/t7-pll.c | 1543 ++++
> > drivers/clk/meson/t7-pll.h | 83 +
> > .../clock/amlogic,t7-peripherals-clkc.h | 410 ++
> > .../dt-bindings/clock/amlogic,t7-pll-clkc.h | 69 +
> > 10 files changed, 8886 insertions(+)
> > create mode 100644 drivers/clk/meson/t7-peripherals.c
> > create mode 100644 drivers/clk/meson/t7-peripherals.h
> > create mode 100644 drivers/clk/meson/t7-pll.c
> > create mode 100644 drivers/clk/meson/t7-pll.h
> > create mode 100644 include/dt-bindings/clock/amlogic,t7-peripherals-clkc.h
> > create mode 100644 include/dt-bindings/clock/amlogic,t7-pll-clkc.h
> >
> > Starting kernel ...
> >
> > uboot time: 14277917 us
> > boot 64bit kernel
> > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd092]
> > [ 0.000000] Linux version 6.8.0-09793-gda876e5b54b3-dirty (tanureal@ryzen) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621, GNU ld (GNU Toolchain for the A-pr4
> > [ 0.000000] KASLR disabled due to lack of seed
> > [ 0.000000] Machine model: Khadas vim4
> > [ 0.000000] efi: UEFI not found.
> > [ 0.000000] OF: reserved mem: 0x0000000005000000..0x00000000052fffff (3072 KiB) nomap non-reusable secmon@5000000
> > [ 0.000000] OF: reserved mem: 0x0000000005300000..0x00000000072fffff (32768 KiB) nomap non-reusable secmon@5300000
> > [ 0.000000] NUMA: No NUMA configuration found
> > [ 0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000000df7fffff]
> > [ 0.000000] NUMA: NODE_DATA [mem 0xdf10c9c0-0xdf10efff]
> > [ 0.000000] Zone ranges:
> > [ 0.000000] DMA [mem 0x0000000000000000-0x00000000df7fffff]
> > [ 0.000000] DMA32 empty
> > [ 0.000000] Normal empty
> > [ 0.000000] Movable zone start for each node
> > [ 0.000000] Early memory node ranges
> > [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000004ffffff]
> > [ 0.000000] node 0: [mem 0x0000000005000000-0x00000000072fffff]
> > [ 0.000000] node 0: [mem 0x0000000007300000-0x00000000df7fffff]
> > [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x00000000df7fffff]
> > [ 0.000000] On node 0, zone DMA: 2048 pages in unavailable ranges
> > [ 0.000000] cma: Reserved 32 MiB at 0x00000000d9800000 on node -1
> > [ 0.000000] psci: probing for conduit method from DT.
> > [ 0.000000] psci: PSCIv1.0 detected in firmware.
> > [ 0.000000] psci: Using standard PSCI v0.2 function IDs
> > [ 0.000000] psci: Trusted OS migration not required
> > [ 0.000000] psci: SMC Calling Convention v1.1
> > [ 0.000000] percpu: Embedded 24 pages/cpu s58152 r8192 d31960 u98304
> > [ 0.000000] Detected VIPT I-cache on CPU0
> > [ 0.000000] CPU features: detected: Spectre-v2
> > [ 0.000000] CPU features: detected: Spectre-v4
> > [ 0.000000] CPU features: detected: Spectre-BHB
> > [ 0.000000] CPU features: detected: ARM erratum 858921
> > [ 0.000000] alternatives: applying boot alternatives
> > [ 0.000000] Kernel command line: root=UUID=a91e7bfe-4263-4e53-867d-7824e7c6a992 rw rootfstype=ext4 console=ttyS0,921600 no_console_suspend earlycon=ttyS0,0xfe078000 khadas_board=VIM4 androidboot.selinux=permissive androidboot.0
> > [ 0.000000] Unknown kernel command line parameters "khadas_board=VIM4", will be passed to user space.
> > [ 0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
> > [ 0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
> > [ 0.000000] Fallback order for Node 0: 0
> > [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 901152
> > [ 0.000000] Policy zone: DMA
> > [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> > [ 0.000000] software IO TLB: SWIOTLB bounce buffer size adjusted to 3MB
> > [ 0.000000] software IO TLB: area num 8.
> > [ 0.000000] software IO TLB: SWIOTLB bounce buffer size roundup to 4MB
> > [ 0.000000] software IO TLB: mapped [mem 0x00000000d8e00000-0x00000000d9200000] (4MB)
> > [ 0.000000] Memory: 3445944K/3661824K available (16896K kernel code, 4426K rwdata, 9184K rodata, 9728K init, 611K bss, 183112K reserved, 32768K cma-reserved)
> > [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
> > [ 0.000000] rcu: Preemptible hierarchical RCU implementation.
> > [ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8.
> > [ 0.000000] Trampoline variant of Tasks RCU enabled.
> > [ 0.000000] Tracing variant of Tasks RCU enabled.
> > [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> > [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
> > [ 0.000000] RCU Tasks: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
> > [ 0.000000] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
> > [ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> > [ 0.000000] GIC: GICv2 detected, but range too small and irqchip.gicv2_force_probe not set
> > [ 0.000000] Root IRQ handler: gic_handle_irq
> > [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
> > [ 0.000000] arch_timer: Enabling local workaround for ARM erratum 858921
> > [ 0.000000] arch_timer: CPU0: Trapping CNTVCT access
> > [ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
> > [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
> > [ 0.000000] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
> > [ 0.000210] Console: colour dummy device 80x25
> > [ 0.000253] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
> > [ 0.000261] pid_max: default: 32768 minimum: 301
> > [ 0.000300] LSM: initializing lsm=capability
> > [ 0.000358] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
> > [ 0.000371] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
> > [ 0.000920] cacheinfo: Unable to detect cache hierarchy for CPU 0
> > [ 0.001389] rcu: Hierarchical SRCU implementation.
> > [ 0.001391] rcu: Max phase no-delay instances is 1000.
> > [ 0.001834] EFI services will not be available.
> > [ 0.001999] smp: Bringing up secondary CPUs ...
> > [ 0.002408] CPU features: detected: ARM erratum 845719
> > [ 0.002426] Detected VIPT I-cache on CPU1
> > [ 0.002516] CPU1: Booted secondary processor 0x0000000100 [0x410fd034]
> > [ 0.003007] Detected VIPT I-cache on CPU2
> > [ 0.003054] CPU2: Booted secondary processor 0x0000000101 [0x410fd034]
> > [ 0.003497] Detected VIPT I-cache on CPU3
> > [ 0.003546] CPU3: Booted secondary processor 0x0000000102 [0x410fd034]
> > [ 0.003988] Detected VIPT I-cache on CPU4
> > [ 0.004038] CPU4: Booted secondary processor 0x0000000103 [0x410fd034]
> > [ 0.004472] Detected VIPT I-cache on CPU5
> > [ 0.004509] arch_timer: Enabling local workaround for ARM erratum 858921
> > [ 0.004519] arch_timer: CPU5: Trapping CNTVCT access
> > [ 0.004527] CPU5: Booted secondary processor 0x0000000001 [0x410fd092]
> > [ 0.004915] Detected VIPT I-cache on CPU6
> > [ 0.004940] arch_timer: Enabling local workaround for ARM erratum 858921
> > [ 0.004946] arch_timer: CPU6: Trapping CNTVCT access
> > [ 0.004951] CPU6: Booted secondary processor 0x0000000002 [0x410fd092]
> > [ 0.005333] Detected VIPT I-cache on CPU7
> > [ 0.005358] arch_timer: Enabling local workaround for ARM erratum 858921
> > [ 0.005364] arch_timer: CPU7: Trapping CNTVCT access
> > [ 0.005369] CPU7: Booted secondary processor 0x0000000003 [0x410fd092]
> > [ 0.005414] smp: Brought up 1 node, 8 CPUs
> > [ 0.005419] SMP: Total of 8 processors activated.
> > [ 0.005421] CPU: All CPU(s) started at EL2
> > [ 0.005434] CPU features: detected: 32-bit EL0 Support
> > [ 0.005437] CPU features: detected: 32-bit EL1 Support
> > [ 0.005440] CPU features: detected: CRC32 instructions
> > [ 0.005485] alternatives: applying system-wide alternatives
> > [ 0.006730] devtmpfs: initialized
> > [ 0.008534] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> > [ 0.008545] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
> > [ 0.008989] pinctrl core: initialized pinctrl subsystem
> > [ 0.009581] DMI not present or invalid.
> > [ 0.011290] NET: Registered PF_NETLINK/PF_ROUTE protocol family
> > [ 0.011944] DMA: preallocated 512 KiB GFP_KERNEL pool for atomic allocations
> > [ 0.012293] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> > [ 0.012711] DMA: preallocated 512 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
> > [ 0.012832] audit: initializing netlink subsys (disabled)
> > [ 0.013075] audit: type=2000 audit(0.012:1): state=initialized audit_enabled=0 res=1
> > [ 0.013508] thermal_sys: Registered thermal governor 'step_wise'
> > [ 0.013512] thermal_sys: Registered thermal governor 'power_allocator'
> > [ 0.013557] cpuidle: using governor menu
> > [ 0.013675] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> > [ 0.013784] ASID allocator initialised with 65536 entries
> > [ 0.014630] Serial: AMBA PL011 UART driver
> > [ 0.017553] Modules: 22496 pages in range for non-PLT usage
> > [ 0.017556] Modules: 514016 pages in range for PLT usage
> > [ 0.017980] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
> > [ 0.017984] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
> > [ 0.017988] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages
> > [ 0.017990] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page
> > [ 0.017993] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
> > [ 0.017995] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
> > [ 0.017997] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages
> > [ 0.018000] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page
> > [ 0.018247] Demotion targets for Node 0: null
> > [ 0.018884] ACPI: Interpreter disabled.
> > [ 0.019584] iommu: Default domain type: Translated
> > [ 0.019587] iommu: DMA domain TLB invalidation policy: strict mode
> > [ 0.019979] SCSI subsystem initialized
> > [ 0.020174] usbcore: registered new interface driver usbfs
> > [ 0.020187] usbcore: registered new interface driver hub
> > [ 0.020200] usbcore: registered new device driver usb
> > [ 0.020434] pps_core: LinuxPPS API ver. 1 registered
> > [ 0.020437] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
> > [ 0.020443] PTP clock support registered
> > [ 0.020487] EDAC MC: Ver: 3.0.0
> > [ 0.020717] scmi_core: SCMI protocol bus registered
> > [ 0.021039] FPGA manager framework
> > [ 0.021076] Advanced Linux Sound Architecture Driver Initialized.
> > [ 0.021612] vgaarb: loaded
> > [ 0.021857] clocksource: Switched to clocksource arch_sys_counter
> > [ 0.021967] VFS: Disk quotas dquot_6.6.0
> > [ 0.021984] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> > [ 0.022062] pnp: PnP ACPI: disabled
> > [ 0.026651] NET: Registered PF_INET protocol family
> > [ 0.026781] IP idents hash table entries: 65536 (order: 7, 524288 bytes, linear)
> > [ 0.028598] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
> > [ 0.028615] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
> > [ 0.028622] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
> > [ 0.028750] TCP bind hash table entries: 32768 (order: 8, 1048576 bytes, linear)
> > [ 0.029019] TCP: Hash tables configured (established 32768 bind 32768)
> > [ 0.029096] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
> > [ 0.029124] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
> > [ 0.029225] NET: Registered PF_UNIX/PF_LOCAL protocol family
> > [ 0.029506] RPC: Registered named UNIX socket transport module.
> > [ 0.029510] RPC: Registered udp transport module.
> > [ 0.029512] RPC: Registered tcp transport module.
> > [ 0.029513] RPC: Registered tcp-with-tls transport module.
> > [ 0.029515] RPC: Registered tcp NFSv4.1 backchannel transport module.
> > [ 0.029524] PCI: CLS 0 bytes, default 64
> > [ 0.029649] Unpacking initramfs...
> > [ 0.033933] kvm [1]: IPA Size Limit: 40 bits
> > [ 0.034713] kvm [1]: Hyp mode initialized successfully
> > [ 0.035476] Initialise system trusted keyrings
> > [ 0.035582] workingset: timestamp_bits=42 max_order=20 bucket_order=0
> > [ 0.035747] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> > [ 0.035906] NFS: Registering the id_resolver key type
> > [ 0.035919] Key type id_resolver registered
> > [ 0.035922] Key type id_legacy registered
> > [ 0.035933] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
> > [ 0.035935] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
> > [ 0.036031] 9p: Installing v9fs 9p2000 file system support
> > [ 0.062587] Key type asymmetric registered
> > [ 0.062596] Asymmetric key parser 'x509' registered
> > [ 0.062657] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
> > [ 0.062661] io scheduler mq-deadline registered
> > [ 0.062664] io scheduler kyber registered
> > [ 0.062688] io scheduler bfq registered
> > [ 0.063318] irq_meson_gpio: 157 to 12 gpio interrupt mux initialized
> > [ 0.068061] EINJ: ACPI disabled.
> > [ 0.072570] amlogic_t7_pll_probe
> > [ 0.072855] amlogic_t7_pll_probe ret 0
> > [ 0.072943] amlogic_a1_periphs_probe
> > [ 0.078155] amlogic_a1_periphs_probe ret 0
> > [ 0.084876] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
> > [ 0.086691] fe078000.serial: ttyS0 at MMIO 0xfe078000 (irq = 14, base_baud = 1500000) is a meson_uart
> > [ 0.086710] printk: legacy console [ttyS0] enabled
> > [ 0.229167] sysfs: cannot create duplicate filename '/class/tty/ttyS0'
> > [ 0.229669] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> > [ 0.230684] Hardware name: Khadas vim4 (DT)
> > [ 0.231205] Call trace:
> > [ 0.231509] dump_backtrace+0x94/0xec
> > [ 0.231963] show_stack+0x18/0x24
> > [ 0.232374] dump_stack_lvl+0x78/0x90
> > [ 0.232829] dump_stack+0x18/0x24
> > [ 0.233241] sysfs_warn_dup+0x64/0x80
> > [ 0.233696] sysfs_do_create_link_sd+0xf0/0xf8
> > [ 0.234248] sysfs_create_link+0x20/0x40
> > [ 0.234736] device_add+0x27c/0x77c
> > [ 0.235169] device_register+0x20/0x30
> > [ 0.235635] tty_register_device_attr+0xfc/0x240
> > [ 0.236209] tty_port_register_device_attr_serdev+0x8c/0xac
> > [ 0.236902] serial_core_register_port+0x318/0x658
> > [ 0.237498] serial_ctrl_register_port+0x10/0x1c
> > [ 0.238072] uart_add_one_port+0x10/0x1c
> > [ 0.238560] meson_uart_probe+0x2c0/0x3b4
> > [ 0.239058] platform_probe+0x68/0xd8
> > [ 0.239513] really_probe+0x148/0x2b4
> > [ 0.239968] __driver_probe_device+0x78/0x12c
> > [ 0.240510] driver_probe_device+0xdc/0x160
> > [ 0.241030] __driver_attach+0x94/0x19c
> > [ 0.241507] bus_for_each_dev+0x74/0xd4
> > [ 0.241983] driver_attach+0x24/0x30
> > [ 0.242428] bus_add_driver+0xe4/0x1e8
> > [ 0.242893] driver_register+0x60/0x128
> > [ 0.243370] __platform_driver_register+0x28/0x34
> > [ 0.243955] meson_uart_platform_driver_init+0x1c/0x28
> > [ 0.244594] do_one_initcall+0x6c/0x1b0
> > [ 0.245071] kernel_init_freeable+0x1cc/0x294
> > [ 0.245613] kernel_init+0x20/0x1dc
> > [ 0.246046] ret_from_fork+0x10/0x20
> > [ 0.246555] meson_uart fe078000.serial: Cannot register tty device on line 0
> > [ 0.247729] msm_serial: driver initialized
> > [ 0.248150] SuperH (H)SCI(F) driver initialized
> > [ 0.248544] STM32 USART driver initialized
> > [ 0.263927] loop: module loaded
> > [ 0.264952] megasas: 07.727.03.00-rc1
> > [ 0.271065] tun: Universal TUN/TAP device driver, 1.6
> > [ 0.271824] thunder_xcv, ver 1.0
> > [ 0.271878] thunder_bgx, ver 1.0
> > [ 0.271956] nicpf, ver 1.0
> > [ 0.273230] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
> > [ 0.273437] hns3: Copyright (c) 2017 Huawei Corporation.
> > [ 0.274148] hclge is initializing
> > [ 0.274541] e1000: Intel(R) PRO/1000 Network Driver
> > [ 0.275116] e1000: Copyright (c) 1999-2006 Intel Corporation.
> > [ 0.275860] e1000e: Intel(R) PRO/1000 Network Driver
> > [ 0.276449] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
> > [ 0.277209] igb: Intel(R) Gigabit Ethernet Network Driver
> > [ 0.277867] igb: Copyright (c) 2007-2014 Intel Corporation.
> > [ 0.278576] igbvf: Intel(R) Gigabit Virtual Function Network Driver
> > [ 0.279330] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
> > [ 0.280319] sky2: driver version 1.30
> > [ 0.281597] VFIO - User Level meta-driver version: 0.3
> > [ 0.283859] usbcore: registered new interface driver usb-storage
> > [ 0.286328] i2c_dev: i2c /dev entries driver
> > [ 0.292404] sdhci: Secure Digital Host Controller Interface driver
> > [ 0.292481] sdhci: Copyright(c) Pierre Ossman
> > [ 0.293577] Synopsys Designware Multimedia Card Interface Driver
> > [ 0.294572] sdhci-pltfm: SDHCI platform and OF driver helper
> > [ 0.296259] ledtrig-cpu: registered to indicate activity on CPUs
> > [ 0.298966] meson-sm: secure-monitor enabled
> > [ 0.299963] usbcore: registered new interface driver usbhid
> > [ 0.299997] usbhid: USB HID core driver
> > [ 0.306803] NET: Registered PF_PACKET protocol family
> > [ 0.306919] 9pnet: Installing 9P2000 support
> > [ 0.307331] Key type dns_resolver registered
> > [ 0.318926] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
> > [ 0.319462] registered taskstats version 1
> > [ 0.319968] Loading compiled-in X.509 certificates
> > [ 0.362771] clk: Disabling unused clocks
> > [ 0.363100] PM: genpd: Disabling unused power domains
> > [ 0.363383] ALSA device list:
> > [ 0.363580] No soundcards found.
> > [ 0.368194] meson-gx-mmc fe08a000.sd: Got CD GPIO
> > [ 0.368524] SError Interrupt on CPU6, code 0x00000000bf000002 -- SError
> > [ 0.368531] CPU: 6 PID: 87 Comm: kworker/u32:3 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> > [ 0.368537] Hardware name: Khadas vim4 (DT)
> > [ 0.368540] Workqueue: async async_run_entry_fn
> > [ 0.368552] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> > [ 0.368556] pc : clk_mux_val_to_index+0x0/0xc0
> > [ 0.368565] lr : clk_mux_get_parent+0x4c/0x84
> > [ 0.368571] sp : ffff800082efba10
> > [ 0.368572] x29: ffff800082efba10 x28: ffff8000823279c0 x27: ffff800082327000
> > [ 0.368578] x26: ffff000004c361c0 x25: 0000000000000000 x24: 0000000000000002
> > [ 0.368584] x23: ffff000003f1d300 x22: ffff000003f1d2a0 x21: ffff000004c37280
> > [ 0.368589] x20: ffff000004c36ec0 x19: ffff000004bba800 x18: 0000000000000020
> > [ 0.368594] x17: ffff000000022000 x16: 0000000000000003 x15: ffffffffffffffff
> > [ 0.368599] x14: ffffffffffffffff x13: 0078756d2364732e x12: 3030306138306566
> > [ 0.368604] x11: 7f7f7f7f7f7f7f7f x10: ffff7fff83438910 x9 : 0000000000000005
> > [ 0.368609] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 05114367045e5359
> > [ 0.368613] x5 : 0000000000000006 x4 : 0000000000000000 x3 : 0000000000000000
> > [ 0.368618] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000004c36ec0
> > [ 0.368624] Kernel panic - not syncing: Asynchronous SError Interrupt
> > [ 0.368626] CPU: 6 PID: 87 Comm: kworker/u32:3 Not tainted 6.8.0-09793-gda876e5b54b3-dirty #15
> > [ 0.368630] Hardware name: Khadas vim4 (DT)
> > [ 0.368631] Workqueue: async async_run_entry_fn
> > [ 0.368635] Call trace:
> > [ 0.368637] dump_backtrace+0x94/0xec
> > [ 0.368644] show_stack+0x18/0x24
> > [ 0.368649] dump_stack_lvl+0x38/0x90
> > [ 0.368656] dump_stack+0x18/0x24
> > [ 0.368661] panic+0x388/0x3c8
> > [ 0.368666] nmi_panic+0x48/0x94
> > [ 0.368670] arm64_serror_panic+0x6c/0x78
> > [ 0.368674] do_serror+0x3c/0x78
> > [ 0.368677] el1h_64_error_handler+0x30/0x48
> > [ 0.368681] el1h_64_error+0x64/0x68
> > [ 0.368684] clk_mux_val_to_index+0x0/0xc0
> > [ 0.368689] __clk_register+0x440/0x82c
> > [ 0.368693] devm_clk_register+0x5c/0xbc
> > [ 0.368697] meson_mmc_clk_init+0x11c/0x2a8
> > [ 0.368702] meson_mmc_probe+0x18c/0x3c0
> > [ 0.368705] platform_probe+0x68/0xd8
> > [ 0.368711] really_probe+0x148/0x2b4
> > [ 0.368714] __driver_probe_device+0x78/0x12c
> > [ 0.368718] driver_probe_device+0xdc/0x160
> > [ 0.368721] __device_attach_driver+0xb8/0x134
> > [ 0.368724] bus_for_each_drv+0x84/0xe0
> > [ 0.368727] __device_attach_async_helper+0xac/0xd0
> > [ 0.368730] async_run_entry_fn+0x34/0xe0
> > [ 0.368734] process_one_work+0x150/0x294
> > [ 0.368740] worker_thread+0x304/0x408
> > [ 0.368744] kthread+0x118/0x11c
> > [ 0.368748] ret_from_fork+0x10/0x20
> > [ 0.368753] SMP: stopping secondary CPUs
> > [ 0.368760] Kernel Offset: disabled
> > [ 0.368761] CPU features: 0x0,00000060,d0080000,0200421b
> > [ 0.368765] Memory Limit: none
> > [ 0.400328] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---
> >
> >
> > --
> > 2.44.0
> >
^ permalink raw reply
* Re: [Linux-stm32] [PATCH net-next 2/2] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Maxime Chevallier @ 2024-04-03 8:12 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Romain Gantois, Rob Herring, Conor Dooley, Maxime Coquelin,
Geert Uytterhoeven, devicetree, Thomas Petazzoni, netdev,
linux-stm32, Magnus Damm, linux-kernel, linux-renesas-soc,
Eric Dumazet, Jose Abreu, Krzysztof Kozlowski, Jakub Kicinski,
Paolo Abeni, Clément Léger, David S. Miller,
linux-arm-kernel
In-Reply-To: <E1rrgQO-005ZOA-KT@rmk-PC.armlinux.org.uk>
Hello Russell,
On Tue, 02 Apr 2024 16:51:48 +0100
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> wrote:
> Use the newly introduced pcs_init() and pcs_exit() operations to
> create and destroy the PCS instance at a more appropriate moment during
> the driver lifecycle, thereby avoiding publishing a network device to
> userspace that has not yet finished its PCS initialisation.
>
> There are other similar issues with this driver which remain
> unaddressed, but these are out of scope for this patch.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Thanks for addressing this,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
^ permalink raw reply
* Re: [PATCH 6/6] iio: adc: ad7173: Add support for AD411x devices
From: Ceclan, Dumitru @ 2024-04-03 8:15 UTC (permalink / raw)
To: David Lechner, dumitru.ceclan
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-iio,
devicetree, linux-kernel
In-Reply-To: <CAMknhBH-YmFrqNTQCB_KafCTxEqSL+36pkE0O44NqiL89hm64Q@mail.gmail.com>
On 02/04/2024 00:53, David Lechner wrote:
> On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
> <devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>>
>> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>>
>> Add support for AD4111/AD4112/AD4114/AD4115/AD4116.
>>
>> The AD411X family encompasses a series of low power, low noise, 24-bit,
>> sigma-delta analog-to-digital converters that offer a versatile range of
>> specifications.
>>
>> This family of ADCs integrates an analog front end suitable for processing
>> both fully differential and single-ended, bipolar voltage inputs
>> addressing a wide array of industrial and instrumentation requirements.
>>
>> - All ADCs have inputs with a precision voltage divider with a division
>> ratio of 10.
>> - AD4116 has 5 low level inputs without a voltage divider.
>> - AD4111 and AD4112 support current inputs (0 mA to 20 mA) using a 50ohm
>> shunt resistor.
>>
>> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
>> ---
>
> ...
>
>> @@ -951,7 +1117,7 @@ static int ad7173_fw_parse_channel_config(struct iio_dev *indio_dev)
>> struct device *dev = indio_dev->dev.parent;
>> struct iio_chan_spec *chan_arr, *chan;
>> unsigned int ain[2], chan_index = 0;
>> - int ref_sel, ret, num_channels;
>> + int ref_sel, ret, reg, num_channels;
>>
>> num_channels = device_get_child_node_count(dev);
>>
>
> Another thing that is missing in this function both for the chips
> being added here and the existing chips are channels for _all_
> possible inputs. The driver is adding a fixed input channel for the
> temperature sensor, as it should. But all of the chips also have a
> similar input channel configuration that measures the reference
> voltage. Currently, there doesn't seem to be a way to make use of this
> feature. I would expect a hard-coded voltage input channel that is
> always added for this reference voltage similar to the temperature
> channel.
>
AD7173-8:
Channel input configs:
AINPOS0: REF+ 10101: 21
AINNEG0: REF- 10110: 22
For the user to define the REF measurement channel:
diff-channels = <21 22>;
So it is possible from the binding side. It would just need support from
the driver as currently any value above the stated number of inputs is
rejected. Maybe document this in a comment like you suggested below.
I really do not agree with using up channels without letting the user
decide. I can accept to dedicate one for the temp where applicable but
more than that and it feels like we are restricting the usage too much.
> The ad717x chips (except AD7173-8 and AD7176-2) also have a common
> mode voltage input ("((AVDD1 − AVSS)/5)") that could work the same.
>
Again, would be resolved if I added support from the driver.
> In the case of the ad717x chips though, it looks like these channels
> are not "fixed" like they are in ad411x. It looks like these inputs
> can be mixed and matched with AINx inputs and/or each other as
> differential pairs. So if that is actually the case, I would expect
> the DT bindings for ad717x to look like adi,ad4130.yaml where these
> additional input sources are listed in the diff-channels property
> instead of having hard-coded channels in the driver like I have
> suggested above.
>
Yep, agree.
> But, as always, fixes for ad717x should be in a separate patch series.
> Still, I think adding a hard-coded channel for the reference voltage
> input for ad411x chips in this patch makes sense.
As stated above, not comfortable with using up channels with hard-coded
values.
^ permalink raw reply
* [PATCH v2] ARM: dts: imx27-phytec: Add USB support
From: Michael Grzeschik @ 2024-04-03 8:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel,
Michael Grzeschik
This patch adds the pinmux and nodes for usbotg and usbh2.
In v6 revision of the pca100 the usb phys were changed to usb3320 which
are connected by their reset pins. We add the phy configuration to the
description.
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
---
Changes in v2:
- changed prefix to "ARM: dts: imx27-phytec:"
- Link to v1: https://lore.kernel.org/r/20240328-pca100-v1-1-58df67c2c950@pengutronix.de
---
.../dts/nxp/imx/imx27-phytec-phycard-s-som.dtsi | 78 ++++++++++++++++++++++
1 file changed, 78 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-som.dtsi b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-som.dtsi
index abc9233c5a1b1..31b3fc972abbf 100644
--- a/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-som.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx27-phytec-phycard-s-som.dtsi
@@ -15,6 +15,22 @@ memory@a0000000 {
device_type = "memory";
reg = <0xa0000000 0x08000000>; /* 128MB */
};
+
+ usbotgphy: usbotgphy {
+ compatible = "usb-nop-xceiv";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotgphy>;
+ reset-gpios = <&gpio2 25 GPIO_ACTIVE_LOW>;
+ #phy-cells = <0>;
+ };
+
+ usbh2phy: usbh2phy {
+ compatible = "usb-nop-xceiv";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh2phy>;
+ reset-gpios = <&gpio2 22 GPIO_ACTIVE_LOW>;
+ #phy-cells = <0>;
+ };
};
&cspi1 {
@@ -84,6 +100,52 @@ MX27_PAD_NFRE_B__NFRE_B 0x0
MX27_PAD_NFWE_B__NFWE_B 0x0
>;
};
+
+ pinctrl_usbotgphy: usbotgphygrp {
+ fsl,pins = <
+ MX27_PAD_USBH1_RCV__GPIO2_25 0x1 /* reset gpio */
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX27_PAD_USBOTG_CLK__USBOTG_CLK 0x0
+ MX27_PAD_USBOTG_DIR__USBOTG_DIR 0x0
+ MX27_PAD_USBOTG_NXT__USBOTG_NXT 0x0
+ MX27_PAD_USBOTG_STP__USBOTG_STP 0x0
+ MX27_PAD_USBOTG_DATA0__USBOTG_DATA0 0x0
+ MX27_PAD_USBOTG_DATA1__USBOTG_DATA1 0x0
+ MX27_PAD_USBOTG_DATA2__USBOTG_DATA2 0x0
+ MX27_PAD_USBOTG_DATA3__USBOTG_DATA3 0x0
+ MX27_PAD_USBOTG_DATA4__USBOTG_DATA4 0x0
+ MX27_PAD_USBOTG_DATA5__USBOTG_DATA5 0x0
+ MX27_PAD_USBOTG_DATA6__USBOTG_DATA6 0x0
+ MX27_PAD_USBOTG_DATA7__USBOTG_DATA7 0x0
+ >;
+ };
+
+ pinctrl_usbh2phy: usbh2phygrp {
+ fsl,pins = <
+ MX27_PAD_USBH1_SUSP__GPIO2_22 0x0 /* reset gpio */
+ >;
+ };
+
+ pinctrl_usbh2: usbh2grp {
+ fsl,pins = <
+ MX27_PAD_USBH2_CLK__USBH2_CLK 0x0
+ MX27_PAD_USBH2_DIR__USBH2_DIR 0x0
+ MX27_PAD_USBH2_NXT__USBH2_NXT 0x0
+ MX27_PAD_USBH2_STP__USBH2_STP 0x0
+ MX27_PAD_CSPI2_SCLK__USBH2_DATA0 0x0
+ MX27_PAD_CSPI2_MOSI__USBH2_DATA1 0x0
+ MX27_PAD_CSPI2_MISO__USBH2_DATA2 0x0
+ MX27_PAD_CSPI2_SS1__USBH2_DATA3 0x0
+ MX27_PAD_CSPI2_SS2__USBH2_DATA4 0x0
+ MX27_PAD_CSPI1_SS2__USBH2_DATA5 0x0
+ MX27_PAD_CSPI2_SS0__USBH2_DATA6 0x0
+ MX27_PAD_USBH2_DATA7__USBH2_DATA7 0x0
+ >;
+ };
};
};
@@ -95,3 +157,19 @@ &nfc {
nand-on-flash-bbt;
status = "okay";
};
+
+&usbotg {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ phy_type = "ulpi";
+ phys = <&usbotgphy>;
+ status = "okay";
+};
+
+&usbh2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh2>;
+ phy_type = "ulpi";
+ phys = <&usbh2phy>;
+ status = "okay";
+};
---
base-commit: 5bab5dc780c9ed0c69fc2f828015532acf4a7848
change-id: 20240328-pca100-a600ac4384e7
Best regards,
--
Michael Grzeschik <m.grzeschik@pengutronix.de>
^ permalink raw reply related
* Re: [PATCH 2/2] mfd: rohm-bd71828: Add software-compatible variant BD71879
From: Matti Vaittinen @ 2024-04-03 8:21 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
devicetree, linux-kernel
In-Reply-To: <20240402193515.513713-3-andreas@kemnade.info>
On 4/2/24 22:35, Andreas Kemnade wrote:
> Add the BD71879 PMIC which is software-compatible to the BD71828, so reuse
> the same device_type enum.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
> drivers/mfd/rohm-bd71828.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mfd/rohm-bd71828.c b/drivers/mfd/rohm-bd71828.c
> index 4a1fa8a0d76a..f0b444690d4d 100644
> --- a/drivers/mfd/rohm-bd71828.c
> +++ b/drivers/mfd/rohm-bd71828.c
> @@ -585,6 +585,10 @@ static const struct of_device_id bd71828_of_match[] = {
> {
> .compatible = "rohm,bd71828",
> .data = (void *)ROHM_CHIP_TYPE_BD71828,
> + }, {
> + .compatible = "rohm,bd71879",
> + /* equivalent from a software point of view */
> + .data = (void *)ROHM_CHIP_TYPE_BD71828,
> }, {
> .compatible = "rohm,bd71815",
> .data = (void *)ROHM_CHIP_TYPE_BD71815,
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Matti Vaittinen @ 2024-04-03 8:23 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
devicetree, linux-kernel
In-Reply-To: <20240402193515.513713-2-andreas@kemnade.info>
On 4/2/24 22:35, Andreas Kemnade wrote:
> As this chip was seen in several devices in the wild, add it.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
Acked-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
> Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> index 0b62f854bf6b..e4df09e8961c 100644
> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> @@ -17,7 +17,9 @@ description: |
>
> properties:
> compatible:
> - const: rohm,bd71828
> + enum:
> + - rohm,bd71828
> + - rohm,bd71879
>
> reg:
> description:
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Hans de Goede @ 2024-04-03 8:31 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <6b47886e-09ac-4cb9-ab53-ca64f5320005@linaro.org>
Hi Krzysztof,
On 4/2/24 3:55 PM, Krzysztof Kozlowski wrote:
> On 02/04/2024 15:21, Gergo Koteles wrote:
>> Newer laptops have FnLock LED.
>>
>> Add a define for this very common function.
>>
>> Signed-off-by: Gergo Koteles <soyer@irl.hu>
>> ---
>> include/dt-bindings/leds/common.h | 1 +
>
> Do we really need to define all these possible LED functions? Please
> link to DTS user for this.
It is useful to have well established names for common
LED functions instead of having each driver come up
with its own name with slightly different spelling
for various fixed function LEDs.
This is even documented in:
Documentation/leds/leds-class.rst :
"""
LED Device Naming
=================
Is currently of the form:
"devicename:color:function"
...
- function:
one of LED_FUNCTION_* definitions from the header
include/dt-bindings/leds/common.h.
"""
Note this even specifies these definitions should go into
include/dt-bindings/leds/common.h .
In this case there is no dts user (yet) only an in kernel
driver which wants to use a LED_FUNCTION_* define to
establish how to identify FN-lock LEDs going forward.
Since a lot of LED_FUNCTION_* defines happen to be used
in dts files these happen to live under include/dt-bindings/
but the dts files are not the only consumer of these defines (1).
IMHO having a hard this must be used in a dts file rule
is not helpful for these kinda files with defines shared
between dts and non dts cases.
If we were to follow this logic then any addition to
include/uapi/linux/input-event-codes.h
must have a dts user before being approved too ? Since
that file is included from include/dt-bindings/input/input.h ?
TL;DR: not only is this patch fine, this is actually
the correct place to add such a define according to
the docs in Documentation/leds/leds-class.rst :
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Regards,
Hans
1) These defines are also used in:
drivers/hid/hid-playstation.c
drivers/hid/hid-nintendo.c
drivers/platform/x86/ideapad-laptop.c
drivers/leds/leds-cht-wcove.c
drivers/leds/simple/simatic-ipc-leds.c
drivers/leds/simple/simatic-ipc-leds-gpio-core.c
^ permalink raw reply
* Re: [PATCH v14 01/18] irqchip/sifive-plic: Convert PLIC driver into a platform driver
From: Lad, Prabhakar @ 2024-04-03 8:29 UTC (permalink / raw)
To: Anup Patel
Cc: Geert Uytterhoeven, Palmer Dabbelt, Paul Walmsley,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Frank Rowand,
Conor Dooley, Marc Zyngier, Björn Töpel, Atish Patra,
Andrew Jones, Sunil V L, Saravana Kannan, Anup Patel, linux-riscv,
linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20240222094006.1030709-2-apatel@ventanamicro.com>
Hi Anup,
On Thu, Feb 22, 2024 at 9:41 AM Anup Patel <apatel@ventanamicro.com> wrote:
>
> The PLIC driver does not require very early initialization so convert
> it into a platform driver.
>
> After conversion, the PLIC driver is probed after CPUs are brought-up
> so setup cpuhp state after context handler of all online CPUs are
> initialized otherwise PLIC driver crashes for platforms with multiple
> PLIC instances.
>
> Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> ---
> drivers/irqchip/irq-sifive-plic.c | 101 ++++++++++++++++++------------
> 1 file changed, 61 insertions(+), 40 deletions(-)
>
This patch seems to have broken things on RZ/Five SoC, after reverting
this patch I get to boot it back again on v6.9-rc2. Looks like there
is some probe order issue after switching to platform driver?
Cheers,
Prabhakar
> diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c
> index 5b7bc4fd9517..7400a07fc479 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -64,6 +64,7 @@
> #define PLIC_QUIRK_EDGE_INTERRUPT 0
>
> struct plic_priv {
> + struct device *dev;
> struct cpumask lmask;
> struct irq_domain *irqdomain;
> void __iomem *regs;
> @@ -406,30 +407,50 @@ static int plic_starting_cpu(unsigned int cpu)
> return 0;
> }
>
> -static int __init __plic_init(struct device_node *node,
> - struct device_node *parent,
> - unsigned long plic_quirks)
> +static const struct of_device_id plic_match[] = {
> + { .compatible = "sifive,plic-1.0.0" },
> + { .compatible = "riscv,plic0" },
> + { .compatible = "andestech,nceplic100",
> + .data = (const void *)BIT(PLIC_QUIRK_EDGE_INTERRUPT) },
> + { .compatible = "thead,c900-plic",
> + .data = (const void *)BIT(PLIC_QUIRK_EDGE_INTERRUPT) },
> + {}
> +};
> +
> +static int plic_probe(struct platform_device *pdev)
> {
> int error = 0, nr_contexts, nr_handlers = 0, i;
> - u32 nr_irqs;
> - struct plic_priv *priv;
> + struct device *dev = &pdev->dev;
> + unsigned long plic_quirks = 0;
> struct plic_handler *handler;
> + struct plic_priv *priv;
> + bool cpuhp_setup;
> unsigned int cpu;
> + u32 nr_irqs;
> +
> + if (is_of_node(dev->fwnode)) {
> + const struct of_device_id *id;
> +
> + id = of_match_node(plic_match, to_of_node(dev->fwnode));
> + if (id)
> + plic_quirks = (unsigned long)id->data;
> + }
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> if (!priv)
> return -ENOMEM;
>
> + priv->dev = dev;
> priv->plic_quirks = plic_quirks;
>
> - priv->regs = of_iomap(node, 0);
> + priv->regs = of_iomap(to_of_node(dev->fwnode), 0);
> if (WARN_ON(!priv->regs)) {
> error = -EIO;
> goto out_free_priv;
> }
>
> error = -EINVAL;
> - of_property_read_u32(node, "riscv,ndev", &nr_irqs);
> + of_property_read_u32(to_of_node(dev->fwnode), "riscv,ndev", &nr_irqs);
> if (WARN_ON(!nr_irqs))
> goto out_iounmap;
>
> @@ -439,13 +460,13 @@ static int __init __plic_init(struct device_node *node,
> if (!priv->prio_save)
> goto out_free_priority_reg;
>
> - nr_contexts = of_irq_count(node);
> + nr_contexts = of_irq_count(to_of_node(dev->fwnode));
> if (WARN_ON(!nr_contexts))
> goto out_free_priority_reg;
>
> error = -ENOMEM;
> - priv->irqdomain = irq_domain_add_linear(node, nr_irqs + 1,
> - &plic_irqdomain_ops, priv);
> + priv->irqdomain = irq_domain_add_linear(to_of_node(dev->fwnode), nr_irqs + 1,
> + &plic_irqdomain_ops, priv);
> if (WARN_ON(!priv->irqdomain))
> goto out_free_priority_reg;
>
> @@ -455,7 +476,7 @@ static int __init __plic_init(struct device_node *node,
> int cpu;
> unsigned long hartid;
>
> - if (of_irq_parse_one(node, i, &parent)) {
> + if (of_irq_parse_one(to_of_node(dev->fwnode), i, &parent)) {
> pr_err("failed to parse parent for context %d.\n", i);
> continue;
> }
> @@ -491,7 +512,7 @@ static int __init __plic_init(struct device_node *node,
>
> /* Find parent domain and register chained handler */
> if (!plic_parent_irq && irq_find_host(parent.np)) {
> - plic_parent_irq = irq_of_parse_and_map(node, i);
> + plic_parent_irq = irq_of_parse_and_map(to_of_node(dev->fwnode), i);
> if (plic_parent_irq)
> irq_set_chained_handler(plic_parent_irq,
> plic_handle_irq);
> @@ -533,20 +554,29 @@ static int __init __plic_init(struct device_node *node,
>
> /*
> * We can have multiple PLIC instances so setup cpuhp state
> - * and register syscore operations only when context handler
> - * for current/boot CPU is present.
> + * and register syscore operations only once after context
> + * handlers of all online CPUs are initialized.
> */
> - handler = this_cpu_ptr(&plic_handlers);
> - if (handler->present && !plic_cpuhp_setup_done) {
> - cpuhp_setup_state(CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING,
> - "irqchip/sifive/plic:starting",
> - plic_starting_cpu, plic_dying_cpu);
> - register_syscore_ops(&plic_irq_syscore_ops);
> - plic_cpuhp_setup_done = true;
> + if (!plic_cpuhp_setup_done) {
> + cpuhp_setup = true;
> + for_each_online_cpu(cpu) {
> + handler = per_cpu_ptr(&plic_handlers, cpu);
> + if (!handler->present) {
> + cpuhp_setup = false;
> + break;
> + }
> + }
> + if (cpuhp_setup) {
> + cpuhp_setup_state(CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING,
> + "irqchip/sifive/plic:starting",
> + plic_starting_cpu, plic_dying_cpu);
> + register_syscore_ops(&plic_irq_syscore_ops);
> + plic_cpuhp_setup_done = true;
> + }
> }
>
> - pr_info("%pOFP: mapped %d interrupts with %d handlers for"
> - " %d contexts.\n", node, nr_irqs, nr_handlers, nr_contexts);
> + pr_info("%pOFP: mapped %d interrupts with %d handlers for %d contexts.\n",
> + to_of_node(dev->fwnode), nr_irqs, nr_handlers, nr_contexts);
> return 0;
>
> out_free_enable_reg:
> @@ -563,20 +593,11 @@ static int __init __plic_init(struct device_node *node,
> return error;
> }
>
> -static int __init plic_init(struct device_node *node,
> - struct device_node *parent)
> -{
> - return __plic_init(node, parent, 0);
> -}
> -
> -IRQCHIP_DECLARE(sifive_plic, "sifive,plic-1.0.0", plic_init);
> -IRQCHIP_DECLARE(riscv_plic0, "riscv,plic0", plic_init); /* for legacy systems */
> -
> -static int __init plic_edge_init(struct device_node *node,
> - struct device_node *parent)
> -{
> - return __plic_init(node, parent, BIT(PLIC_QUIRK_EDGE_INTERRUPT));
> -}
> -
> -IRQCHIP_DECLARE(andestech_nceplic100, "andestech,nceplic100", plic_edge_init);
> -IRQCHIP_DECLARE(thead_c900_plic, "thead,c900-plic", plic_edge_init);
> +static struct platform_driver plic_driver = {
> + .driver = {
> + .name = "riscv-plic",
> + .of_match_table = plic_match,
> + },
> + .probe = plic_probe,
> +};
> +builtin_platform_driver(plic_driver);
> --
> 2.34.1
>
>
> _______________________________________________
> 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] arm64: dts: qcom: qcs6490-rb3gen2: Specify zap region for gpu
From: Dmitry Baryshkov @ 2024-04-03 8:31 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Caleb Connolly, Komal Bajaj, Naina Mehta,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240402-rb3gen2-gpu-v1-1-a51bb6080968@quicinc.com>
On Wed, 3 Apr 2024 at 06:33, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
>
> Without the zap region defined the enabled GPU will, if able to find the
> other firmware files, attempt to initialize itself without the zap
> firmware loading, which causes the rb3gen2 to freeze or crash.
>
> Add the zap-shader node and define the memory-region and firmware path
> to avoid this problem.
>
> Fixes: 04cf333afc75 ("arm64: dts: qcom: Add base qcs6490-rb3gen2 board dts")
> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> index 63ebe0774f1d..5b81b5e0b4ce 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> @@ -471,6 +471,13 @@ &gcc {
> <GCC_WPSS_RSCP_CLK>;
> };
>
> +&gpu {
Hmm, Is the GPU enabled by default? It should probably be fixed. I
think we usually do not enable the GPU by default on SoC.dtsi.
But now I understand, why it is marked with Fixes:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> + zap-shader {
> + memory-region = <&gpu_microcode_mem>;
> + firmware-name = "qcom/qcs6490/a660_zap.mbn";
> + };
> +};
> +
> &qupv3_id_0 {
> status = "okay";
> };
>
> ---
> base-commit: 727900b675b749c40ba1f6669c7ae5eb7eb8e837
> change-id: 20240326-rb3gen2-gpu-4343c5dc7e40
>
> Best regards,
> --
> Bjorn Andersson <quic_bjorande@quicinc.com>
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Hans de Goede @ 2024-04-03 8:33 UTC (permalink / raw)
To: Gergo Koteles, Krzysztof Kozlowski, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <2710283677cf12ca6b826565ec39652f560a43d8.camel@irl.hu>
Hi George,
On 4/2/24 8:50 PM, Gergo Koteles wrote:
> Hi Krzysztof,
>
> On Tue, 2024-04-02 at 20:08 +0200, Krzysztof Kozlowski wrote:
>> On 02/04/2024 16:36, Gergo Koteles wrote:
>>> Hi Krzysztof,
>>>
>>> On Tue, 2024-04-02 at 15:55 +0200, Krzysztof Kozlowski wrote:
>>>>
>>>> Do we really need to define all these possible LED functions? Please
>>>> link to DTS user for this.
>>>>
>>>
>>> I think for userspace it's easier to support an LED with a specified
>>> name than to use various sysfs attributes. LED devices are easy to find
>>> because they available are in the /sys/class/leds/ directory.
>>> So I think it's a good thing to define LED names somewhere.
>>
>> You did not add anything for user-space, but DT bindings. We do not keep
>> here anything for user-space.
>>
>
> The LED_FUNCTION_KBD_BACKLIGHT confused me. Ok, this shouldn't be here,
> I will remove it from v2.
I don't believe that is necessary, see my direct reply to Krzysztof first
email about this. According to Documentation/leds/leds-class.rst
you did exactly the right thing.
Also thank you for your interesting contribution. I have only briefly
looked over your other 2 patches, but I like the concept.
I'll hopefully have time to do a full review coming Monday.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: stmmac: dwmac-socfpga: use pcs_init/pcs_exit
From: Russell King (Oracle) @ 2024-04-03 8:34 UTC (permalink / raw)
To: Romain Gantois
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, Clément Léger, Thomas Petazzoni,
netdev, devicetree, linux-kernel, linux-renesas-soc, linux-stm32,
linux-arm-kernel
In-Reply-To: <E1rrgQO-005ZOA-KT@rmk-PC.armlinux.org.uk>
On Tue, Apr 02, 2024 at 04:51:48PM +0100, Russell King (Oracle) wrote:
> Use the newly introduced pcs_init() and pcs_exit() operations to
> create and destroy the PCS instance at a more appropriate moment during
> the driver lifecycle, thereby avoiding publishing a network device to
> userspace that has not yet finished its PCS initialisation.
>
> There are other similar issues with this driver which remain
> unaddressed, but these are out of scope for this patch.
Just for the record...
Digging into the history of this driver, the init-after-publish issue
was introduced by commit 3c201b5a84ed ("net: stmmac: socfpga: Remove
re-registration of reset controller") which gives information on why
calling the PHY configuration before stmmac_dvr_probe() didn't work.
This was further modified by 56868deece92 ("stmmac: dwmac-socfpga: add
PM ops and resume function").
I haven't decided what can be done about that yet - and I'm tempted to
leave it as-is for the time being until more of stmmac gets cleaned up.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Krzysztof Kozlowski @ 2024-04-03 8:36 UTC (permalink / raw)
To: Hans de Goede, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <39acb3b9-a69f-4654-9749-a9af42fea39e@redhat.com>
On 03/04/2024 10:31, Hans de Goede wrote:
> Hi Krzysztof,
>
> On 4/2/24 3:55 PM, Krzysztof Kozlowski wrote:
>> On 02/04/2024 15:21, Gergo Koteles wrote:
>>> Newer laptops have FnLock LED.
>>>
>>> Add a define for this very common function.
>>>
>>> Signed-off-by: Gergo Koteles <soyer@irl.hu>
>>> ---
>>> include/dt-bindings/leds/common.h | 1 +
>>
>> Do we really need to define all these possible LED functions? Please
>> link to DTS user for this.
>
> It is useful to have well established names for common
> LED functions instead of having each driver come up
> with its own name with slightly different spelling
> for various fixed function LEDs.
>
> This is even documented in:
>
> Documentation/leds/leds-class.rst :
>
> """
> LED Device Naming
> =================
>
> Is currently of the form:
>
> "devicename:color:function"
>
> ...
>
>
> - function:
> one of LED_FUNCTION_* definitions from the header
> include/dt-bindings/leds/common.h.
> """
>
> Note this even specifies these definitions should go into
> include/dt-bindings/leds/common.h .
>
> In this case there is no dts user (yet) only an in kernel
> driver which wants to use a LED_FUNCTION_* define to
> establish how to identify FN-lock LEDs going forward.
Ack, reasonable.
>
> Since a lot of LED_FUNCTION_* defines happen to be used
> in dts files these happen to live under include/dt-bindings/
> but the dts files are not the only consumer of these defines (1).
Yes, but if there was no DTS consumer at all, then it is not a binding,
so it should not go to include/dt-bindings.
>
> IMHO having a hard this must be used in a dts file rule
> is not helpful for these kinda files with defines shared
> between dts and non dts cases.
>
> If we were to follow this logic then any addition to
>
> include/uapi/linux/input-event-codes.h
>
> must have a dts user before being approved too ? Since
> that file is included from include/dt-bindings/input/input.h ?
Wait, that's UAPI :) and we just share the constants. That's kind of
special case, but I get what you mean.
>
> TL;DR: not only is this patch fine, this is actually
> the correct place to add such a define according to
> the docs in Documentation/leds/leds-class.rst :
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: ls1028a: sl28: split variant 3/ads2 carrier
From: Michael Walle @ 2024-04-03 8:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Michael Walle
The devicetree files can be (re-)used in u-boot now, they are imported
on a regular basis (see OF_UPSTREAM option) there. Up until now, it
didn't matter for linux and there was just a combined devicetree
"-var3-ads2" (with ads2 being the carrier board). But if the devicetree
files are now reused in u-boot, we need to have an individual "-var3"
variant, because the bootloader is just using the bare "varN" devicetree
files. Split the "var3" off of the "-var3-ads2" devicetree.
Signed-off-by: Michael Walle <mwalle@kernel.org>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../fsl-ls1028a-kontron-sl28-var3-ads2.dts | 2 +-
.../fsl-ls1028a-kontron-sl28-var3.dts | 18 ++++++++++++++++++
3 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 045250d0a040..9319791f298c 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-kbox-a-230-ls.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var1.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var2.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var3.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var3-ads2.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var4.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
index ed4e69e87e30..195bdbafdf7c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
@@ -10,7 +10,7 @@
/dts-v1/;
#include <dt-bindings/clock/fsl,qoriq-clockgen.h>
-#include "fsl-ls1028a-kontron-sl28.dts"
+#include "fsl-ls1028a-kontron-sl28-var3.dts"
/ {
model = "Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
new file mode 100644
index 000000000000..08851ca407a8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Device Tree file for the Kontron SMARC-sAL28 board.
+ *
+ * This is for the network variant 3 which has one ethernet ports.
+ *
+ * Copyright (C) 2024 Michael Walle <michael@walle.cc>
+ *
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1028a-kontron-sl28.dts"
+
+/ {
+ model = "Kontron SMARC-sAL28 (Single PHY)";
+ compatible = "kontron,sl28-var3", "kontron,sl28", "fsl,ls1028a";
+};
--
2.39.2
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Hans de Goede @ 2024-04-03 8:39 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <368e9817-0000-4f69-9f09-568827466121@linaro.org>
Hi,
On 4/3/24 10:36 AM, Krzysztof Kozlowski wrote:
> On 03/04/2024 10:31, Hans de Goede wrote:
>> Hi Krzysztof,
>>
>> On 4/2/24 3:55 PM, Krzysztof Kozlowski wrote:
>>> On 02/04/2024 15:21, Gergo Koteles wrote:
>>>> Newer laptops have FnLock LED.
>>>>
>>>> Add a define for this very common function.
>>>>
>>>> Signed-off-by: Gergo Koteles <soyer@irl.hu>
>>>> ---
>>>> include/dt-bindings/leds/common.h | 1 +
>>>
>>> Do we really need to define all these possible LED functions? Please
>>> link to DTS user for this.
>>
>> It is useful to have well established names for common
>> LED functions instead of having each driver come up
>> with its own name with slightly different spelling
>> for various fixed function LEDs.
>>
>> This is even documented in:
>>
>> Documentation/leds/leds-class.rst :
>>
>> """
>> LED Device Naming
>> =================
>>
>> Is currently of the form:
>>
>> "devicename:color:function"
>>
>> ...
>>
>>
>> - function:
>> one of LED_FUNCTION_* definitions from the header
>> include/dt-bindings/leds/common.h.
>> """
>>
>> Note this even specifies these definitions should go into
>> include/dt-bindings/leds/common.h .
>>
>> In this case there is no dts user (yet) only an in kernel
>> driver which wants to use a LED_FUNCTION_* define to
>> establish how to identify FN-lock LEDs going forward.
>
> Ack, reasonable.
>
>>
>> Since a lot of LED_FUNCTION_* defines happen to be used
>> in dts files these happen to live under include/dt-bindings/
>> but the dts files are not the only consumer of these defines (1).
>
> Yes, but if there was no DTS consumer at all, then it is not a binding,
> so it should not go to include/dt-bindings.
>
>>
>> IMHO having a hard this must be used in a dts file rule
>> is not helpful for these kinda files with defines shared
>> between dts and non dts cases.
>>
>> If we were to follow this logic then any addition to
>>
>> include/uapi/linux/input-event-codes.h
>>
>> must have a dts user before being approved too ? Since
>> that file is included from include/dt-bindings/input/input.h ?
>
> Wait, that's UAPI :) and we just share the constants. That's kind of
> special case, but I get what you mean.
>
>>
>> TL;DR: not only is this patch fine, this is actually
>> the correct place to add such a define according to
>> the docs in Documentation/leds/leds-class.rst :
>>
>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Thanks. Is it ok for me to merge this through the pdx86
tree (once I've reviewed the other 2 patches) ?
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v6 08/11] pinctrl: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
From: Yangyu Chen @ 2024-04-03 8:38 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-riscv, Conor Dooley, Damien Le Moal, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Guo Ren, Michael Turquette, Stephen Boyd, Philipp Zabel,
linux-gpio, linux-clk, devicetree, linux-kernel
In-Reply-To: <CACRpkdY1wpGM7M5QV5rN0M6JMN_yugQJ7CEtnQjzsheD5AT23A@mail.gmail.com>
> On Apr 2, 2024, at 20:31, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Sat, Mar 23, 2024 at 1:13 PM Yangyu Chen <cyy@cyyself.name> wrote:
>
>> Since SOC_FOO should be deprecated from patch [1], and cleanup for other
>> SoCs is already on the mailing list [2,3,4], we remove the use of
>> SOC_CANAAN and introduced SOC_CANAAN_K210 for K210-specific drivers,
>>
>> Thus, we replace its drivers depends on SOC_CANAAN_K210 and default select
>> when it has the symbol SOC_CANAAN_K210.
>>
>> [1] https://lore.kernel.org/linux-riscv/20221121221414.109965-1-conor@kernel.org/
>> [2] https://lore.kernel.org/linux-riscv/20240305-praying-clad-c4fbcaa7ed0a@spud/
>> [3] https://lore.kernel.org/linux-riscv/20240305-fled-undrilled-41dc0c46bb29@spud/
>> [4] https://lore.kernel.org/linux-riscv/20240305-stress-earflap-d7ddb8655a4d@spud/
>>
>> Signed-off-by: Yangyu Chen <cyy@cyyself.name>
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
Please add Acked-by to this email [1]. I will separate them in the next
revision.
[1]
https://lore.kernel.org/linux-riscv/tencent_DB11214C8D0D7C48829ADA128E7BB8F13108@qq.com/
Thanks.
> Is this patch something I can just apply to the pinctrl tree?
>
I think not. As Conor said.
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 00/12] Use clksel for more clocks for dra7
From: Tony Lindgren @ 2024-04-03 8:43 UTC (permalink / raw)
To: linux-omap; +Cc: Benoît Cousson, devicetree
In-Reply-To: <20240328113133.GG5132@atomide.com>
* Tony Lindgren <tony@atomide.com> [240328 11:31]:
> * Tony Lindgren <tony@atomide.com> [240327 09:39]:
> > The DPLL output clocks are problematic at this point as the
> > clock driver makes assumptions based on no reg property in
> > _register_dpll_x2() for the ti,omap4-dpll-x2-clock. After
> > the driver issues are solved, the DPLL output related clocks
> > can also use the clksel binding.
>
> Actually the driver needs changes only for clocks where there's no
> reg entry. For the clocks with a reg entry like dpll_per m2 outputs,
> the following seems to work based on light testing.
Oh but below dpll_per_x2_ck has no reg yet we now add the reg property.
Likely the additional patch below can't be used without driver changes
for _register_dpll_x2().
Regards,
Tony
> 8< -----------------
> diff --git a/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi b/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
> --- a/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/ti/omap/dra7xx-clocks.dtsi
> @@ -1425,6 +1425,7 @@ dpll_per_byp_mux: clock@23 {
> };
> };
>
> + /* CM_CLKSEL_DPLL_PER */
> dpll_per_ck: clock@140 {
> #clock-cells = <0>;
> compatible = "ti,omap4-dpll-clock";
> @@ -1433,16 +1434,43 @@ dpll_per_ck: clock@140 {
> reg = <0x0140>, <0x0144>, <0x014c>, <0x0148>;
> };
>
> - dpll_per_m2_ck: clock-dpll-per-m2-8@150 {
> - #clock-cells = <0>;
> - compatible = "ti,divider-clock";
> - clock-output-names = "dpll_per_m2_ck";
> - clocks = <&dpll_per_ck>;
> - ti,max-div = <31>;
> - ti,autoidle-shift = <8>;
> - reg = <0x0150>;
> - ti,index-starts-at-one;
> - ti,invert-autoidle-bit;
> + /* CM_DIV_M2_DPLL_PER */
> + clock@150 {
> + compatible = "ti,clksel";
> + reg = <0x150>;
> + #clock-cells = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dpll_per_m2x2_ck: clock@0 {
> + reg = <0>;
> + #clock-cells = <0>;
> + compatible = "ti,divider-clock";
> + clock-output-names = "dpll_per_m2x2_ck";
> + clocks = <&dpll_per_x2_ck>;
> + ti,max-div = <31>;
> + ti,autoidle-shift = <8>;
> + ti,index-starts-at-one;
> + ti,invert-autoidle-bit;
> + };
> +
> + dpll_per_m2_ck: clock@8 {
> + compatible = "fixed-factor-clock";
> + reg = <8>;
> + #clock-cells = <0>;
> + clocks = <&dpll_per_m2x2_ck>;
> + clock-mult = <1>;
> + clock-div = <2>;
> + clock-output-names = "dpll_per_m2_ck";
> + };
> +
> + dpll_per_x2_ck: clock@10 {
> + reg = <10>;
> + #clock-cells = <0>;
> + compatible = "ti,omap4-dpll-x2-clock";
> + clock-output-names = "dpll_per_x2_ck";
> + clocks = <&dpll_per_ck>;
> + };
> };
>
> func_96m_aon_dclk_div: clock-func-96m-aon-dclk-div {
> @@ -1503,13 +1531,6 @@ dpll_pcie_ref_m2_ck: clock-dpll-pcie-ref-m2-8@210 {
> ti,invert-autoidle-bit;
> };
>
> - dpll_per_x2_ck: clock-dpll-per-x2 {
> - #clock-cells = <0>;
> - compatible = "ti,omap4-dpll-x2-clock";
> - clock-output-names = "dpll_per_x2_ck";
> - clocks = <&dpll_per_ck>;
> - };
> -
> dpll_per_h11x2_ck: clock-dpll-per-h11x2-8@158 {
> #clock-cells = <0>;
> compatible = "ti,divider-clock";
> @@ -1558,18 +1579,6 @@ dpll_per_h14x2_ck: clock-dpll-per-h14x2-8@164 {
> ti,invert-autoidle-bit;
> };
>
> - dpll_per_m2x2_ck: clock-dpll-per-m2x2-8@150 {
> - #clock-cells = <0>;
> - compatible = "ti,divider-clock";
> - clock-output-names = "dpll_per_m2x2_ck";
> - clocks = <&dpll_per_x2_ck>;
> - ti,max-div = <31>;
> - ti,autoidle-shift = <8>;
> - reg = <0x0150>;
> - ti,index-starts-at-one;
> - ti,invert-autoidle-bit;
> - };
> -
> dpll_usb_clkdcoldo: clock-dpll-usb-clkdcoldo {
> #clock-cells = <0>;
> compatible = "fixed-factor-clock";
> --
> 2.44.0
>
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Andy Shevchenko @ 2024-04-03 8:44 UTC (permalink / raw)
To: Cristian Marussi
Cc: Peng Fan, Peng Fan (OSS), Sudeep Holla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij, Dan Carpenter,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, Oleksii Moisieiev
In-Reply-To: <Zg0N8S05D329BVjN@pluto>
On Wed, Apr 3, 2024 at 11:06 AM Cristian Marussi
<cristian.marussi@arm.com> wrote:
> On Tue, Apr 02, 2024 at 07:39:44PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 2, 2024 at 6:58 PM Cristian Marussi
> > <cristian.marussi@arm.com> wrote:
> > > On Tue, Apr 02, 2024 at 04:06:06PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Apr 2, 2024 at 10:48 AM Cristian Marussi
> > > > <cristian.marussi@arm.com> wrote:
> > > > > On Sun, Mar 31, 2024 at 01:44:28PM +0000, Peng Fan wrote:
> > > > > > > Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) kirjoitti:
...
> > > > > > > > +#include <linux/module.h>
> > > > > > > > +#include <linux/scmi_protocol.h>
> > > > > > > > +#include <linux/slab.h>
> > > > > > >
> > > > > > > This is semi-random list of headers. Please, follow IWYU principle (include
> > > > > > > what you use). There are a lot of inclusions I see missing (just in the context of
> > > > > > > this page I see bits.h, types.h, and asm/byteorder.h).
> > > > > >
> > > > > > Is there any documentation about this requirement?
> > > > > > Some headers are already included by others.
> > > >
> > > > The documentation here is called "a common sense".
> > > > The C language is built like this and we expect that nobody will
> > > > invest into the dependency hell that we have already, that's why IWYU
> > > > principle, please follow it.
> > >
> > > Yes, but given that we have a growing number of SCMI protocols there is a
> > > common local protocols.h header to group all includes needed by any
> > > protocols: the idea behind this (and the devm_ saga down below) was to ease
> > > development of protocols, since there are lots of them and growing, given
> > > the SCMI spec is extensible.
> >
> > Yes, and what you are effectively suggesting is: "Technical debt? Oh,
> > fine, we do not care!" This is not good. I'm in a long term of
> > cleaning up the dependency hell in the kernel (my main focus is
> > kernel.h for now) and I am talking from my experience. I do not like
> > what people are doing in 95% of the code, that's why I really want to
> > stop the bad practices as soon as possible.
>
> Not at all, the aim was exactly the opposite, avoiding that some protocol
> could have been written without all the needed includes: since a basic set
> of headers is definitely common to any protocol you may think to write,
> grouping all there was meant to avoid this...I thought that by moving the
> problem away in one single internal common header was easier to monitor.
Which may or may not be okay. It plays too smart, so the end developer
won't care about real headers they need as they are the only ones who
know the source code in the best possible way.
> I certainly maybe wrong, but I dont see how you can deduce I dont care...
See above, the protocols.h it's a reincarnation (much less twisted and
ugly, though) of something like kernel.h. Do you know why we have a
split to headers instead of having everything in one? It speeds up a
build, it separates namespace (to the extent of what we call
"namespace" in C language), it makes the modularization (of the source
code) better (easier to avoid considering what's not needed), and so
on. I don't think making a "common" header is a good idea.
> ...and maybe, only maybe, what that 95% of people is trying to do in their
> horrible code is to deliver the best reasonably possible thing within their
> timeline while you are barking at them in chase of never to be released utter
> perfection.
Yeah. That's why it's good to teach people about many aspects of the C
language (which is not popular, in particular due to these nuances,
nowadays and we are starving for good developers).
> > Last to add, but not least is that your code may be used as an example
> > for others, hence we really have to do our best in order to avoid bad
> > design, practices, and cargo cults. If this requires more refactoring
> > of the existing code, then do it sooner than later.
...
> > > > > Andy made (mostly) the same remarks on this same patch ~1-year ago on
> > > > > this same patch while it was posted by Oleksii.
> > > > >
> > > > > And I told that time that most of the remarks around devm_ usage were
> > > > > wrong due to how the SCMI core handles protocol initialization (using a
> > > > > devres group transparently).
> > > > >
> > > > > This is what I answered that time.
> > > > >
> > > > > https://lore.kernel.org/linux-arm-kernel/ZJ78hBcjAhiU+ZBO@e120937-lin/#t
> > > > >
> > > > > I wont repeat myself, but, in a nutshell the memory allocation like it
> > > > > is now is fine: a bit happens via devm_ at protocol initialization, the
> > > > > other is doe via explicit kmalloc at runtime and freed via kfree at
> > > > > remove time (if needed...i.e. checking the present flag of some structs)
> > > >
> > > > This sounds like a mess. devm_ is expected to be used only for the
> > > > ->probe() stage, otherwise you may consider cleanup.h (__free() macro)
> > > > to have automatic free at the paths where memory is not needed.
> > >
> > > Indeed, this protocol_init code is called by the SCMI core once for all when
> > > an SCMI driver tries at first to use this specific protocol by 'getting' its
> > > protocol_ops, so it is indeed called inside the probe chain of the driver:
> > > at this point you *can* decide to use devres to allocate memory and be assured
> > > that if the init fails, or when the driver cease to use this protocol (calling
> > > its remove()) and no other driver is using it, all the stuff that have been
> > > allocated related to this protocol will be released by the core for you.
> > > (using an internal devres group)
> > >
> > > Without this you should handle manually all the deallocation manually on
> > > the init error-paths AND also provide all the cleanup explicitly when
> > > the protocol is no more used by any driver (multiple users of the same
> > > protocol instance are possible)...for all protocols.
> >
> > Yes. Is it a problem?
>
> Well, no, but is it not a repetitive and error-prone process ?
Yes. That's why we now have cleanup.h. Please, consider using it instead.
> Is it not the exact reason why devres management exist in first place, to avoid
> repetitive manual alloc/free of resources and related pitfalls ? (even though
> certainly it is normally used in a more conventional and straightforward way)
No. Its scope is to clean the probe-remove parts, one should not
spread it otherwise and one definitely should know its limitations and
corner cases (I even gave some examples back in ca. 2017 in one of my
presentation WRT typical mistakes the developers make
> The idea was to give some sort of aid in the SCMI stack for writing protocols,
> so regarding mem_mgmt, I just built on top of devres facilities, not invented
> anything, to try to avoid repetitions and let the core handle mem allocs/free
> during the probe phases as much as possible: in pinctrl case would be
> particularly trivial to instead manually allocate stuff at init (due to many
> lazy delayed allocations) but other protocols need a lot more to be done at init,
> frequently in a loop to allocate multiple resources descriptors, and manually
> undoing all of that on each error-path and on cleanup is definitely error-prone
> and a pain.
I understand the motivation, but again, devm is a beast in the corner
cases. I believe Laurent Pinchart gave a presentation about how bad
devm can hit you if you don't know what you are doing (OTOH it's hard
to know with devm).
> Last but not least, this whole thing was designed to address the needs of the
> protocols that existed at that time....it is only now with pinctrl lazy-allocations
> at runtime that the ugly cohexistence of devm_ and non-devm allocations became a
> thing....so clearly the thing needs to be improved/rethinked...even dropped if no
> more fitting...
>
> ... or alternatively since devres allocations are anyway optional, you could just
> use regular kmalloc/kfree for this protocol and avoid this dual handling...
Probably, just have a look at cleanup.h.
> ...this was just to put things in context...and I'll happily let Sudeep decide
> what he prefers in the immediate for pinctrl or more in general about all the
> scmi devres, that I've got enough of these pleasant interactions for now...
As I said, it's your call, I'm not preventing you from applying
whatever is going on in the SCMI subsystem. Just tried to point out
the problem(s).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS configuration support
From: Odelu Kukatla @ 2024-04-03 8:45 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Georgi Djakov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Kees Cook, cros-qcom-dts-watchers, Gustavo A . R . Silva,
linux-arm-msm, linux-pm, devicetree, linux-kernel,
linux-hardening, quic_rlaggysh, quic_mdtipton
In-Reply-To: <d59896bb-a559-4013-a615-37bb43278b2e@linaro.org>
On 3/27/2024 2:26 AM, Konrad Dybcio wrote:
> On 25.03.2024 7:16 PM, Odelu Kukatla wrote:
>> It adds QoS support for QNOC device and includes support for
>> configuring priority, priority forward disable, urgency forwarding.
>> This helps in priortizing the traffic originating from different
>> interconnect masters at NoC(Network On Chip).
>>
>> Signed-off-by: Odelu Kukatla <quic_okukatla@quicinc.com>
>> ---
>
> [...]
>
>>
>> + if (desc->config) {
>> + struct resource *res;
>> + void __iomem *base;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + goto skip_qos_config;
>> +
>> + base = devm_ioremap_resource(dev, res);
>
> You were asked to substitute this call like 3 times already..
>
> devm_platform_get_and_ioremap_resource
>
> or even better, devm_platform_ioremap_resource
>
> [...]
>
>> @@ -70,6 +102,7 @@ struct qcom_icc_node {
>> u64 max_peak[QCOM_ICC_NUM_BUCKETS];
>> struct qcom_icc_bcm *bcms[MAX_BCM_PER_NODE];
>> size_t num_bcms;
>> + const struct qcom_icc_qosbox *qosbox;
>
> I believe I came up with a better approach for storing this.. see [1]
>
> Konrad
>
> [1] https://lore.kernel.org/linux-arm-msm/20240326-topic-rpm_icc_qos_cleanup-v1-4-357e736792be@linaro.org/
>
I see in this series, QoS parameters are moved into struct qcom_icc_desc.
Even though we program QoS at Provider/Bus level, it is property of the node/master connected to a Bus/NoC.
It will be easier later to know which master's QoS we are programming if we add in node data.
Readability point of view, it might be good to keep QoS parameters in node data.
Thanks,
Odelu
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Krzysztof Kozlowski @ 2024-04-03 8:46 UTC (permalink / raw)
To: Hans de Goede, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <4956933c-49c4-49ab-a91a-7e0efcc211d5@redhat.com>
On 03/04/2024 10:39, Hans de Goede wrote:
>>>
>>> must have a dts user before being approved too ? Since
>>> that file is included from include/dt-bindings/input/input.h ?
>>
>> Wait, that's UAPI :) and we just share the constants. That's kind of
>> special case, but I get what you mean.
>>
>>>
>>> TL;DR: not only is this patch fine, this is actually
>>> the correct place to add such a define according to
>>> the docs in Documentation/leds/leds-class.rst :
>>>
>>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>
>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> Thanks. Is it ok for me to merge this through the pdx86
> tree (once I've reviewed the other 2 patches) ?
You need to sync (ack) with LED folks, because by default this should go
via LED subsystem.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 07/21] virt: geniezone: Add vm capability check
From: Yi-De Wu (吳一德) @ 2024-04-03 8:50 UTC (permalink / raw)
To: corbet@lwn.net, robh+dt@kernel.org, catalin.marinas@arm.com,
conor+dt@kernel.org, richardcochran@gmail.com,
Yingshiuan Pan (潘穎軒),
krzysztof.kozlowski+dt@linaro.org, matthias.bgg@gmail.com,
Ze-yu Wang (王澤宇),
angelogioacchino.delregno@collabora.com, will@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
quic_tsoni@quicinc.com, MY Chuang (莊明躍),
Kevenny Hsieh (謝宜芸),
devicetree@vger.kernel.org,
PeiLun Suei (隋培倫),
Liju-clr Chen (陳麗如), dbrazdil@google.com,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
Shawn Hsiao (蕭志祥), linux-doc@vger.kernel.org,
Chi-shen Yeh (葉奇軒)
In-Reply-To: <c027bf67-e9b2-4eb2-9dee-a47a9c3bdd8a@collabora.com>
On Thu, 2024-02-01 at 10:44 +0100, AngeloGioacchino Del Regno wrote:
> Il 29/01/24 09:32, Yi-De Wu ha scritto:
> > From: "Yingshiuan Pan" <yingshiuan.pan@mediatek.com>
> >
> > Inquire the `capability support` on GenieZone hypervisor.
> > Example:
> > `GZVM_CAP_PROTECTED_VM` or `GZVM_CAP_VM_GPA_SIZE`.
> >
> > Signed-off-by: Yingshiuan Pan <yingshiuan.pan@mediatek.com>
> > Signed-off-by: Jerry Wang <ze-yu.wang@mediatek.com>
> > Signed-off-by: kevenny hsieh <kevenny.hsieh@mediatek.com>
> > Signed-off-by: Liju Chen <liju-clr.chen@mediatek.com>
> > Signed-off-by: Yi-De Wu <yi-de.wu@mediatek.com>
> > ---
> > arch/arm64/geniezone/gzvm_arch_common.h | 2 +
> > arch/arm64/geniezone/vm.c | 122
> > ++++++++++++++++++++++++
> > drivers/virt/geniezone/gzvm_main.c | 27 ++++++
> > drivers/virt/geniezone/gzvm_vm.c | 21 ++++
> > include/linux/gzvm_drv.h | 5 +
> > include/uapi/linux/gzvm.h | 31 ++++++
> > 6 files changed, 208 insertions(+)
> >
> > diff --git a/arch/arm64/geniezone/gzvm_arch_common.h
> > b/arch/arm64/geniezone/gzvm_arch_common.h
> > index 2f66e496dfae..383af0829f11 100644
> > --- a/arch/arm64/geniezone/gzvm_arch_common.h
> > +++ b/arch/arm64/geniezone/gzvm_arch_common.h
> > @@ -13,6 +13,7 @@ enum {
> > GZVM_FUNC_DESTROY_VM = 1,
> > GZVM_FUNC_SET_MEMREGION = 4,
> > GZVM_FUNC_PROBE = 12,
> > + GZVM_FUNC_ENABLE_CAP = 13,
>
> GZVM_FUNC_PROBE = 12,
> GZVM_FUNC_ENABLE_CAP,
>
Given that this is an API from the kernel to the hypervisor, it may be
utilized with various toolchains. Our intention is to explicitly assign
values to prevent any unexpected compiler behavior. For further
details, we'd like to refer to the discussion below.
https://lore.kernel.org/all/20200318125003.GA2727094@kroah.com/
> > NR_GZVM_FUNC,
> > };
> >
>
> Regards,
> Angelo
>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: add LED_FUNCTION_FNLOCK
From: Hans de Goede @ 2024-04-03 8:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, Gergo Koteles, Ike Panhc, Ilpo Järvinen,
Pavel Machek, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: platform-driver-x86, linux-kernel, linux-leds, devicetree
In-Reply-To: <17a700a7-44f0-4e46-9a0c-4c2da44c9e27@linaro.org>
Hi,
On 4/3/24 10:46 AM, Krzysztof Kozlowski wrote:
> On 03/04/2024 10:39, Hans de Goede wrote:
>>>>
>>>> must have a dts user before being approved too ? Since
>>>> that file is included from include/dt-bindings/input/input.h ?
>>>
>>> Wait, that's UAPI :) and we just share the constants. That's kind of
>>> special case, but I get what you mean.
>>>
>>>>
>>>> TL;DR: not only is this patch fine, this is actually
>>>> the correct place to add such a define according to
>>>> the docs in Documentation/leds/leds-class.rst :
>>>>
>>>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>>
>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> Thanks. Is it ok for me to merge this through the pdx86
>> tree (once I've reviewed the other 2 patches) ?
>
> You need to sync (ack) with LED folks, because by default this should go
> via LED subsystem.
Ok, will do.
Pavel, Lee can you give me an ack for merging this through the pdx86 tree?
Regards,
Hans
^ permalink raw reply
* [PATCH v11 1/7] dt-bindings: usb: usbmisc-imx: add fsl,imx8ulp-usbmisc compatible
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
Add "fsl,imx8ulp-usbmisc" compatible.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v3:
- new patch due to missed this little one
Changes in v4:
- no changes
Changes in v5:
- add Acked-by tag
Changes in v6:
- no changes
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- no changes
---
Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
index 2d3589d284b2..0a6e7ac1b37e 100644
--- a/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
+++ b/Documentation/devicetree/bindings/usb/fsl,usbmisc.yaml
@@ -33,6 +33,7 @@ properties:
- fsl,imx7ulp-usbmisc
- fsl,imx8mm-usbmisc
- fsl,imx8mn-usbmisc
+ - fsl,imx8ulp-usbmisc
- const: fsl,imx7d-usbmisc
- const: fsl,imx6q-usbmisc
- items:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] ARM: dts: n900: set charge current limit to 950mA
From: Tony Lindgren @ 2024-04-03 9:03 UTC (permalink / raw)
To: Sicelo A. Mhlongo
Cc: devicetree, Benoît Cousson, Krzysztof Kozlowski,
Conor Dooley, linux-pm, pali, sre, spinal.by, maemo-leste,
linux-omap
In-Reply-To: <20240228083846.2401108-2-absicsz@gmail.com>
* Sicelo A. Mhlongo <absicsz@gmail.com> [240228 10:40]:
> From: Arthur Demchenkov <spinal.by@gmail.com>
>
> The vendor kernel used 950mA as the default. The same value works fine on
> the mainline Linux kernel, and has been tested extensively under Maemo
> Leste [1] and postmarketOS, who have been using it for a number of years.
Thanks applying into omap-for-v6.10/dt.
Tony
> [1] https://github.com/maemo-leste/n9xx-linux/commit/fbc4ce7a84e59215914a8981afe918002b191493
^ permalink raw reply
* [PATCH v11 2/7] arm64: dts: imx8ulp: add usb nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
Add USB nodes on i.MX8ULP platform which has 2 USB controllers.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- no changes
Changes in v3:
- no changes
Changes in v4:
- no changes
Changes in v5:
- no changes
Changes in v6:
- drop usbphy aliases
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- adjust reg order
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 62 ++++++++++++++++++++++
1 file changed, 62 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index c4a0082f30d3..cbed01bb8cc0 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -472,6 +472,68 @@ usdhc2: mmc@298f0000 {
status = "disabled";
};
+ usbotg1: usb@29900000 {
+ compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+ reg = <0x29900000 0x200>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB0>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_USB0>;
+ phys = <&usbphy1>;
+ fsl,usbmisc = <&usbmisc1 0>;
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x8>;
+ rx-burst-size-dword = <0x8>;
+ status = "disabled";
+ };
+
+ usbmisc1: usbmisc@29900200 {
+ compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x29900200 0x200>;
+ #index-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@29910000 {
+ compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+ reg = <0x29910000 0x10000>;
+ interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB0_PHY>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ usbotg2: usb@29920000 {
+ compatible = "fsl,imx8ulp-usb", "fsl,imx7ulp-usb", "fsl,imx6ul-usb";
+ reg = <0x29920000 0x200>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB1>;
+ power-domains = <&scmi_devpd IMX8ULP_PD_USDHC2_USB1>;
+ phys = <&usbphy2>;
+ fsl,usbmisc = <&usbmisc2 0>;
+ ahb-burst-config = <0x0>;
+ tx-burst-size-dword = <0x8>;
+ rx-burst-size-dword = <0x8>;
+ status = "disabled";
+ };
+
+ usbmisc2: usbmisc@29920200 {
+ compatible = "fsl,imx8ulp-usbmisc", "fsl,imx7d-usbmisc",
+ "fsl,imx6q-usbmisc";
+ reg = <0x29920200 0x200>;
+ #index-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy2: usb-phy@29930000 {
+ compatible = "fsl,imx8ulp-usbphy", "fsl,imx7ulp-usbphy";
+ reg = <0x29930000 0x10000>;
+ interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&pcc4 IMX8ULP_CLK_USB1_PHY>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
fec: ethernet@29950000 {
compatible = "fsl,imx8ulp-fec", "fsl,imx6ul-fec", "fsl,imx6q-fec";
reg = <0x29950000 0x10000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v11 3/7] arm64: dts: imx8ulp-evk: enable usb nodes and add ptn5150 nodes
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
Enable 2 USB nodes and add 2 PTN5150 nodes on i.MX8ULP evk board.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v2:
- fix format as suggusted by Fabio
- add PTN5150 nodes
Changes in v3:
- no changes
Changes in v4:
- no changes
Changes in v5:
- no changes
Changes in v6:
- no changes
Changes in v7:
- no changes
Changes in v8:
- no changes
Changes in v9:
- no changes
Changes in v10:
- no changes
Changes in v11:
- fix indent
- adjust order
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 84 +++++++++++++++++++
1 file changed, 84 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 24bb253b938d..e937e5f8fa8b 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -127,12 +127,70 @@ &lpi2c7 {
pinctrl-1 = <&pinctrl_lpi2c7>;
status = "okay";
+ ptn5150_1: typec@1d {
+ compatible = "nxp,ptn5150";
+ reg = <0x1d>;
+ int-gpios = <&gpiof 3 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec1>;
+ status = "disabled";
+ };
+
pcal6408: gpio@21 {
compatible = "nxp,pcal9554b";
reg = <0x21>;
gpio-controller;
#gpio-cells = <2>;
};
+
+ ptn5150_2: typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ int-gpios = <&gpiof 5 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_typec2>;
+ status = "disabled";
+ };
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb1>;
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ over-current-active-low;
+ status = "okay";
+};
+
+&usbphy1 {
+ fsl,tx-d-cal = <110>;
+ status = "okay";
+};
+
+&usbmisc1 {
+ status = "okay";
+};
+
+&usbotg2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb2>;
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ over-current-active-low;
+ status = "okay";
+};
+
+&usbphy2 {
+ fsl,tx-d-cal = <110>;
+ status = "okay";
+};
+
+&usbmisc2 {
+ status = "okay";
};
&usdhc0 {
@@ -224,6 +282,32 @@ MX8ULP_PAD_PTE13__LPI2C7_SDA 0x20
>;
};
+ pinctrl_typec1: typec1grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF3__PTF3 0x3
+ >;
+ };
+
+ pinctrl_typec2: typec2grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF5__PTF5 0x3
+ >;
+ };
+
+ pinctrl_usb1: usb1grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF2__USB0_ID 0x10003
+ MX8ULP_PAD_PTF4__USB0_OC 0x10003
+ >;
+ };
+
+ pinctrl_usb2: usb2grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTD23__USB1_ID 0x10003
+ MX8ULP_PAD_PTF6__USB1_OC 0x10003
+ >;
+ };
+
pinctrl_usdhc0: usdhc0grp {
fsl,pins = <
MX8ULP_PAD_PTD1__SDHC0_CMD 0x3
--
2.34.1
^ 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