Re: [PATCH v5 00/12] tracing: fprobe: rethook: Use ftrace_regs instead of pt_regs
On Thu, Sep 28, 2023 at 6:21 PM Masami Hiramatsu wrote: > > > Thus, what I need is to make fprobe to use function-graph tracer's shadow > stack and trampoline instead of rethook. This may need to generalize its > interface so that we can share it between fprobe and function-graph tracer, > but we don't need to involve rethook and kretprobes anymore. ... > And need to add patches > > - Introduce a generized function exit hook interface for ftrace. > - Replace rethook in fprobe with the function exit hook interface. you mean that rethook will be removed after that?
[PATCH] ring-buffer: Update "shortest_full" in polling
From: "Steven Rostedt (Google)"
It was discovered that the ring buffer polling was incorrectly stating
that read would not block, but that's because polling did not take into
account that reads will block if the "buffer-percent" was set. Instead,
the ring buffer polling would say reads would not block if there was any
data in the ring buffer. This was incorrect behavior from a user space
point of view. This was fixed by commit 42fb0a1e84ff by having the polling
code check if the ring buffer had more data than what the user specified
"buffer percent" had.
The problem now is that the polling code did not register itself to the
writer that it wanted to wait for a specific "full" value of the ring
buffer. The result was that the writer would wake the polling waiter
whenever there was a new event. The polling waiter would then wake up, see
that there's not enough data in the ring buffer to notify user space and
then go back to sleep. The next event would wake it up again.
Before the polling fix was added, the code would wake up around 100 times
for a hackbench 30 benchmark. After the "fix", due to the constant waking
of the writer, it would wake up over 11, times! It would never leave
the kernel, so the user space behavior was still "correct", but this
definitely is not the desired effect.
To fix this, have the polling code add what it's waiting for to the
"shortest_full" variable, to tell the writer not to wake it up if the
buffer is not as full as it expects to be.
Note, after this fix, it appears that the waiter is now woken up around 2x
the times it was before (~200). This is a tremendous improvement from the
11,000 times, but I will need to spend some time to see why polling is
more aggressive in its wakeups than the read blocking code.
Cc: sta...@vger.kernel.org
Fixes: 42fb0a1e84ff ("tracing/ring-buffer: Have polling block on watermark")
Reported-by: Julia Lawall
Signed-off-by: Steven Rostedt (Google)
---
kernel/trace/ring_buffer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 28daf0ce95c5..515cafdb18d9 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -1137,6 +1137,9 @@ __poll_t ring_buffer_poll_wait(struct trace_buffer
*buffer, int cpu,
if (full) {
poll_wait(filp, >full_waiters, poll_table);
work->full_waiters_pending = true;
+ if (!cpu_buffer->shortest_full ||
+ cpu_buffer->shortest_full > full)
+ cpu_buffer->shortest_full = full;
} else {
poll_wait(filp, >waiters, poll_table);
work->waiters_pending = true;
--
2.40.1
[ANNOUNCE] 5.10.194-rt95
Hello RT-list!
I'm pleased to announce the 5.10.194-rt95 stable release.
This release is an RT-only update. All the changes here are specific to RT.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v5.10-rt
Head SHA1: e9e1d0b892ed4e46c4d83b53f0f39880e37f8d92
Or to build 5.10.194-rt95 directly, the following patches should be applied:
https://www.kernel.org/pub/linux/kernel/v5.x/linux-5.10.tar.xz
https://www.kernel.org/pub/linux/kernel/v5.x/patch-5.10.194.xz
https://www.kernel.org/pub/linux/kernel/projects/rt/5.10/older/patch-5.10.194-rt95.patch.xz
Signing key fingerprint:
9354 0649 9972 8D31 D464 D140 F394 A423 F8E6 7C26
All keys used for the above files and repositories can be found on the
following git repository:
git://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git
Enjoy!
Luis
Changes from v5.10.194-rt94:
---
Luis Claudio R. Goncalves (1):
Linux 5.10.194-rt95
Wang Yong (1):
arm64: signal: Use ARCH_RT_DELAYS_SIGNAL_SEND
---
arch/arm64/include/asm/signal.h | 12
arch/arm64/kernel/signal.c | 9 +
localversion-rt | 2 +-
3 files changed, 22 insertions(+), 1 deletion(-)
---
diff --git a/arch/arm64/include/asm/signal.h b/arch/arm64/include/asm/signal.h
new file mode 100644
index 0..0fb418cf4c17a
--- /dev/null
+++ b/arch/arm64/include/asm/signal.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __ARM64_ASM_SIGNAL_H
+#define __ARM64_ASM_SIGNAL_H
+
+#include
+#include
+
+#if defined(CONFIG_PREEMPT_RT)
+#define ARCH_RT_DELAYS_SIGNAL_SEND
+#endif
+
+#endif
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 94eed0dc3afcd..5b08f55ec85d9 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -929,6 +929,15 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
} else {
local_daif_restore(DAIF_PROCCTX);
+#ifdef ARCH_RT_DELAYS_SIGNAL_SEND
+ if (unlikely(current->forced_info.si_signo)) {
+ struct task_struct *t = current;
+
+ force_sig_info(>forced_info);
+ t->forced_info.si_signo = 0;
+ }
+#endif
+
if (thread_flags & _TIF_UPROBE)
uprobe_notify_resume(regs);
diff --git a/localversion-rt b/localversion-rt
index 8d02a9bac5002..5a28f0a65d160 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt94
+-rt95
Re: [PATCH v2] tracing: relax trace_event_eval_update() execution with cond_resched()
On Fri, Sep 29, 2023 at 12:17 PM Clément Léger wrote: > > When kernel is compiled without preemption, the eval_map_work_func() > (which calls trace_event_eval_update()) will not be preempted up to its > complete execution. This can actually cause a problem since if another > CPU call stop_machine(), the call will have to wait for the > eval_map_work_func() function to finish executing in the workqueue > before being able to be scheduled. This problem was observe on a SMP > system at boot time, when the CPU calling the initcalls executed > clocksource_done_booting() which in the end calls stop_machine(). We > observed a 1 second delay because one CPU was executing > eval_map_work_func() and was not preempted by the stop_machine() task. > > Adding a call to cond_resched() in trace_event_eval_update() allows > other tasks to be executed and thus continue working asynchronously > like before without blocking any pending task at boot time. > > Signed-off-by: Clément Léger > --- > > Changes in v2: > - Use cond_resched() instead of schedule() > > kernel/trace/trace_events.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c > index 91951d038ba4..f49d6ddb6342 100644 > --- a/kernel/trace/trace_events.c > +++ b/kernel/trace/trace_events.c > @@ -2770,6 +2770,7 @@ void trace_event_eval_update(struct trace_eval_map > **map, int len) > update_event_fields(call, map[i]); > } > } > + cond_resched(); > } > up_write(_event_sem); > } (First email got rejected as gmail decided to switch back the format to html :(). Sorry for the noise. Thanks for the fix. The boot time improvement is evident in both spike/Qemu. FWIW Tested-by: Atish Patra Reviewed-by: Atish Patra > -- > 2.40.1 >
[PATCH v2] tracing: relax trace_event_eval_update() execution with cond_resched()
When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to cond_resched() in trace_event_eval_update() allows other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Signed-off-by: Clément Léger --- Changes in v2: - Use cond_resched() instead of schedule() kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 91951d038ba4..f49d6ddb6342 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2770,6 +2770,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_fields(call, map[i]); } } + cond_resched(); } up_write(_event_sem); } -- 2.40.1
Re: [PATCH] remoteproc: zynqmp: change tcm address translation method
On Mon, Sep 25, 2023 at 10:26:48AM -0700, Tanmay Shah wrote:
> Introduce device address in hardcode TCM table.
> Device address is used for address translation.
> Also, previous method(hack) to mask few bits from address
> to achieve address translation is removed
>
> Signed-off-by: Tanmay Shah
> ---
> drivers/remoteproc/xlnx_r5_remoteproc.c | 58 +
> 1 file changed, 20 insertions(+), 38 deletions(-)
>
Applied.
Thanks,
Mathieu
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c
> b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index efd758c2f4ed..4395edea9a64 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -39,12 +39,14 @@ enum zynqmp_r5_cluster_mode {
> * struct mem_bank_data - Memory Bank description
> *
> * @addr: Start address of memory bank
> + * @da: device address
> * @size: Size of Memory bank
> * @pm_domain_id: Power-domains id of memory bank for firmware to turn on/off
> * @bank_name: name of the bank for remoteproc framework
> */
> struct mem_bank_data {
> phys_addr_t addr;
> + u32 da;
> size_t size;
> u32 pm_domain_id;
> char *bank_name;
> @@ -76,18 +78,18 @@ struct mbox_info {
> * accepted for system-dt specifications and upstreamed in linux kernel
> */
> static const struct mem_bank_data zynqmp_tcm_banks_split[] = {
> - {0xffe0UL, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each */
> - {0xffe2UL, 0x1UL, PD_R5_0_BTCM, "btcm0"},
> - {0xffe9UL, 0x1UL, PD_R5_1_ATCM, "atcm1"},
> - {0xffebUL, 0x1UL, PD_R5_1_BTCM, "btcm1"},
> + {0xffe0UL, 0x0, 0x1UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 64KB each
> */
> + {0xffe2UL, 0x2, 0x1UL, PD_R5_0_BTCM, "btcm0"},
> + {0xffe9UL, 0x0, 0x1UL, PD_R5_1_ATCM, "atcm1"},
> + {0xffebUL, 0x2, 0x1UL, PD_R5_1_BTCM, "btcm1"},
> };
>
> /* In lockstep mode cluster combines each 64KB TCM and makes 128KB TCM */
> static const struct mem_bank_data zynqmp_tcm_banks_lockstep[] = {
> - {0xffe0UL, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB each */
> - {0xffe2UL, 0x2UL, PD_R5_0_BTCM, "btcm0"},
> - {0, 0, PD_R5_1_ATCM, ""},
> - {0, 0, PD_R5_1_BTCM, ""},
> + {0xffe0UL, 0x0, 0x2UL, PD_R5_0_ATCM, "atcm0"}, /* TCM 128KB
> each */
> + {0xffe2UL, 0x2, 0x2UL, PD_R5_0_BTCM, "btcm0"},
> + {0, 0, 0, PD_R5_1_ATCM, ""},
> + {0, 0, 0, PD_R5_1_BTCM, ""},
> };
>
> /**
> @@ -534,30 +536,6 @@ static int tcm_mem_map(struct rproc *rproc,
> /* clear TCMs */
> memset_io(va, 0, mem->len);
>
> - /*
> - * The R5s expect their TCM banks to be at address 0x0 and 0x2000,
> - * while on the Linux side they are at 0xffex.
> - *
> - * Zero out the high 12 bits of the address. This will give
> - * expected values for TCM Banks 0A and 0B (0x0 and 0x2).
> - */
> - mem->da &= 0x000f;
> -
> - /*
> - * TCM Banks 1A and 1B still have to be translated.
> - *
> - * Below handle these two banks' absolute addresses (0xffe9 and
> - * 0xffeb) and convert to the expected relative addresses
> - * (0x0 and 0x2).
> - */
> - if (mem->da == 0x9 || mem->da == 0xB)
> - mem->da -= 0x9;
> -
> - /* if translated TCM bank address is not valid report error */
> - if (mem->da != 0x0 && mem->da != 0x2) {
> - dev_err(>dev, "invalid TCM address: %x\n", mem->da);
> - return -EINVAL;
> - }
> return 0;
> }
>
> @@ -579,6 +557,7 @@ static int add_tcm_carveout_split_mode(struct rproc
> *rproc)
> u32 pm_domain_id;
> size_t bank_size;
> char *bank_name;
> + u32 da;
>
> r5_core = rproc->priv;
> dev = r5_core->dev;
> @@ -591,6 +570,7 @@ static int add_tcm_carveout_split_mode(struct rproc
> *rproc)
>*/
> for (i = 0; i < num_banks; i++) {
> bank_addr = r5_core->tcm_banks[i]->addr;
> + da = r5_core->tcm_banks[i]->da;
> bank_name = r5_core->tcm_banks[i]->bank_name;
> bank_size = r5_core->tcm_banks[i]->size;
> pm_domain_id = r5_core->tcm_banks[i]->pm_domain_id;
> @@ -603,11 +583,11 @@ static int add_tcm_carveout_split_mode(struct rproc
> *rproc)
> goto release_tcm_split;
> }
>
> - dev_dbg(dev, "TCM carveout split mode %s addr=%llx, size=0x%lx",
> - bank_name, bank_addr, bank_size);
> + dev_dbg(dev, "TCM carveout split mode %s addr=%llx, da=0x%x,
> size=0x%lx",
> + bank_name, bank_addr, da, bank_size);
>
> rproc_mem = rproc_mem_entry_init(dev, NULL, bank_addr,
> - bank_size, bank_addr,
> + bank_size, da,
>
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
Hello Masami, Thank you for your feedback. Il giorno ven 29 set 2023 alle ore 13:28 Masami Hiramatsu ha scritto: > > On Wed, 27 Sep 2023 17:35:16 + > "Alessandro Carminati (Red Hat)" wrote: > > > It is not uncommon for drivers or modules related to similar peripherals > > to have symbols with the exact same name. > > While this is not a problem for the kernel's binary itself, it becomes an > > issue when attempting to trace or probe specific functions using > > infrastructure like ftrace or kprobe. > > > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > > symbol information from the kernel's ELF binary. However, when multiple > > symbols share the same name, the standard nm output does not differentiate > > between them. This can lead to confusion and difficulty when trying to > > probe the intended symbol. > > > > ~ # cat /proc/kallsyms | grep " name_show" > > 8c4f76d0 t name_show > > 8c9cccb0 t name_show > > 8cb0ac20 t name_show > > 8cc728c0 t name_show > > 8ce0efd0 t name_show > > 8ce126c0 t name_show > > 8ce1dd20 t name_show > > 8ce24e70 t name_show > > 8d1104c0 t name_show > > 8d1fe480 t name_show > > > > kas_alias addresses this challenge by enhancing symbol names with > > meaningful suffixes generated from the source file and line number > > during the kernel build process. > > These newly generated aliases provide tracers with the ability to > > comprehend the symbols they are interacting with when utilizing the > > ftracefs interface. > > This approach may also allow for the probing by name of previously > > inaccessible symbols. > > > > ~ # cat /proc/kallsyms | grep gic_mask_irq > > d15671e505ac t gic_mask_irq > > d15671e505ac t gic_mask_irq@drivers_irqchip_irq_gic_c_167 > > d15671e532a4 t gic_mask_irq > > d15671e532a4 t gic_mask_irq@drivers_irqchip_irq_gic_v3_c_407 > > ~ # > > > > Changes from v1: > > - Integrated changes requested by Masami to exclude symbols with prefixes > > "_cfi" and "_pfx". > > - Introduced a small framework to handle patterns that need to be excluded > > from the alias production. > > - Excluded other symbols using the framework. > > - Introduced the ability to discriminate between text and data symbols. > > - Added two new config symbols in this version: CONFIG_KALLSYMS_ALIAS_DATA, > > which allows data for data, and CONFIG_KALLSYMS_ALIAS_DATA_ALL, which > > excludes all filters and provides an alias for each duplicated symbol. > > > > https://lore.kernel.org/all/20230711151925.1092080-1-alessandro.carmin...@gmail.com/ > > > > Changes from v2: > > - Alias tags are created by querying DWARF information from the vmlinux. > > - The filename + line number is normalized and appended to the original > > name. > > - The tag begins with '@' to indicate the symbol source. > > - Not a change, but worth mentioning, since the alias is added to the > > existing list, the old duplicated name is preserved, and the livepatch > > way of dealing with duplicates is maintained. > > - Acknowledging the existence of scenarios where inlined functions > > declared in header files may result in multiple copies due to compiler > > behavior, though it is not actionable as it does not pose an operational > > issue. > > - Highlighting a single exception where the same name refers to different > > functions: the case of "compat_binfmt_elf.c," which directly includes > > "binfmt_elf.c" producing identical function copies in two separate > > modules. > > > > https://lore.kernel.org/all/20230714150326.1152359-1-alessandro.carmin...@gmail.com/ > > > > Changes from v3: > > - kas_alias was rewritten in Python to create a more concise and > > maintainable codebase. > > - The previous automation process used by kas_alias to locate the vmlinux > > and the addr2line has been replaced with an explicit command-line switch > > for specifying these requirements. > > - addr2line has been added into the main Makefile. > > - A new command-line switch has been introduced, enabling users to extend > > the alias to global data names. > > > > https://lore.kernel.org/all/20230828080423.3539686-1-alessandro.carmin...@gmail.com/ > > > > Changes from v4: > > - Fixed the O= build issue > > - The tool halts execution upon encountering major issues, thereby ensuring > > the pipeline is interrupted. > > - A cmdline option to specify the source directory added. > > - Minor code adjusments. > > - Tested on mips32 and i386 > > > > https://lore.kernel.org/all/20230919193948.465340-1-alessandro.carmin...@gmail.com/ > > > > NOTE: > > About the symbols name duplication that happens as consequence of the > > inclusion compat_binfmt_elf.c does, it is evident that this corner is > > inherently challenging the addr2line approach. > > Attempting to conceal this limitation would be counterproductive. > > > > compat_binfmt_elf.c includes directly
Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control Interface busses
On 29/09/2023 16:25, Konrad Dybcio wrote: Not actually a required clock for the clock controller. I suspect the same is true for dispcc and videocc though it would also mean the respective drivers would need to switch on < DISPx_CAMERA_AHB_CLK> or < GCC_VIDEO_AHB_CLK> prior to accessing registers inside the ip blocks which may not currently be the case. Feels like a bit of a contrary answer but my reading is the GCC_IPBLOCK_AHB_CLK clocks belong in the drivers not the clock controllers.. or at least that's true for sm8250/camcc I believe the idea here would be that registering GCC_IP_AHB_CLK as a pm_clk for the clock controller would make that clock turn on when IPBLOCK_CC is accessed (e.g. when we turn on IPBLOCK_CORE_CLK), so that it doesn't need to be duplicated in each and every end device. Konrad Yeah I mean I accept the logic - the core AHB clock is effectively gated by the ipblockcc even though they originate from different places in hardware - and _when_ do you want one clock without the other ? Never except at probe() time for the ipblockcc. Then again if you can show the clock dependency tree of camera or disp requires GCC_IP_AHB_CLK you could make the argument the dt requires the clock dependency defined in that block. I'd say we should offline this from Luca's patches tho :) for me anyway the first two are fine. Agree #3 is verboten. No new empty nodes. --- bod
Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control Interface busses
On 29.09.2023 17:22, Bryan O'Donoghue wrote:
> On 29/09/2023 15:18, Konrad Dybcio wrote:
>> On 29.09.2023 16:15, Bryan O'Donoghue wrote:
>>> On 29/09/2023 14:35, Konrad Dybcio wrote:
On 9/29/23 10:01, Luca Weiss wrote:
> Add the CCI busses found on sc7280 and their pinctrl states.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 136
> +++
> 1 file changed, 136 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 66f1eb83cca7..65550de2e4ff 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -3793,6 +3793,86 @@ videocc: clock-controller@aaf {
> #power-domain-cells = <1>;
> };
> + cci0: cci@ac4a000 {
> + compatible = "qcom,sc7280-cci", "qcom,msm8996-cci";
> + reg = <0 0x0ac4a000 0 0x1000>;
> + interrupts = ;
> + power-domains = < CAM_CC_TITAN_TOP_GDSC>;
> +
> + clocks = < CAM_CC_CAMNOC_AXI_CLK>,
> + < CAM_CC_SLOW_AHB_CLK_SRC>,
> + < CAM_CC_CPAS_AHB_CLK>,
> + < CAM_CC_CCI_0_CLK>,
> + < CAM_CC_CCI_0_CLK_SRC>;
> + clock-names = "camnoc_axi",
> + "slow_ahb_src",
> + "cpas_ahb",
> + "cci",
> + "cci_src";
I guess this is more of a question to e.g. Bryan, but are all of these
clocks actually necessary?
Konrad
>>> Hmm its a good question, we generally take the approach of adopting all of
>>> the downstream clocks for these camera interfaces verbatim.
>>>
>>> The clock plan for this part only calls out cci_X_clk and cci_x_clk_src for
>>> the CCI however we know that to be incomplete since we *absolutely* need to
>>> have the AXI for the block clocked to access those registers, same deal
>>> with the AHB bus.
>>>
>>> AXI: registers
>>> AHB: data
>>>
>>> In the above list the only clock you might conceivably not need is
>>> CPAS_AHB_CLK.
>>>
>>> Let me zap that clock from sdm845 since I have an rb3 right in front of me
>>> and see what happens.
>>>
>>> Crash and reset
>>>
>>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>>> @@ -4402,13 +4402,11 @@ cci: cci@ac4a000 {
>>> clocks = <_camcc CAM_CC_CAMNOC_AXI_CLK>,
>>> <_camcc CAM_CC_SOC_AHB_CLK>,
>>> <_camcc CAM_CC_SLOW_AHB_CLK_SRC>,
>>> - <_camcc CAM_CC_CPAS_AHB_CLK>,
>>> <_camcc CAM_CC_CCI_CLK>,
>>> <_camcc CAM_CC_CCI_CLK_SRC>;
>>> clock-names = "camnoc_axi",
>>> "soc_ahb",
>>> "slow_ahb_src",
>>> - "cpas_ahb",
>>> "cci",
>>> "cci_src";
>>>
>>>
>>> I think the list is good tbh
>> WDYT about camcc consuming ahb, like dispcc does?
>> AXI, hmm.. not quite sure what to do with it
>>
>> Konrad
>
> Hmm on which platform, camcc clock depds on sdm845 looks very sparse to me.
>
> 8550 OTOH
>
> dispcc: clock-controller@af0 {
> compatible = "qcom,sm8550-dispcc";
> reg = <0 0x0af0 0 0x2>;
> clocks = <_tcxo_div2>,
> <_tcxo_ao_div2>,
> < GCC_DISP_AHB_CLK>,
>
> videocc: clock-controller@aaf {
> compatible = "qcom,sm8550-videocc";
> reg = <0 0x0aaf 0 0x1>;
> clocks = <_tcxo_div2>,
> < GCC_VIDEO_AHB_CLK>;
>
> sm8250
>
> camcc: clock-controller@ad0 {
> compatible = "qcom,sm8250-camcc";
> reg = <0 0x0ad0 0 0x1>;
> clocks = < GCC_CAMERA_AHB_CLK>,
>
> I think those DISP_AHB, VIDEO_AHB_CLK, CAMERA_AHB_CLKs should live in the
> display, video and camss blocks i.e. they are not clocks that you require to
> access the clock controller registers themselves...
>
> I'm seeing for the most part these MEDIAIPBLOCK_AHB_CLKs don't come from the
> GCC AHB clock but from another root clock generator.
>
> bi_tcxo ->
> cam_cc_pll0_out_main ->
> cam_cc_pll0_out_even ->
> cam_cc_pll0_out_odd ->
> cam_cc_pll2_out_main ->
> cam_cc_slow_ahb_clk_src ->
> camcc_bps_ahb_clk
> camcc_ipe_0_ahb_clk
> ...
> camcc_core_ahb_clk
>
> Lets see what happens to sm8250 if we remove CAMERA_AHB_CLK from the camera
> clock controller @ camcc: clock-controller@ad0 {} I don't believe that is
>
Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control Interface busses
On 29/09/2023 15:18, Konrad Dybcio wrote:
On 29.09.2023 16:15, Bryan O'Donoghue wrote:
On 29/09/2023 14:35, Konrad Dybcio wrote:
On 9/29/23 10:01, Luca Weiss wrote:
Add the CCI busses found on sc7280 and their pinctrl states.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 136
+++
1 file changed, 136 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..65550de2e4ff 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3793,6 +3793,86 @@ videocc: clock-controller@aaf {
#power-domain-cells = <1>;
};
+ cci0: cci@ac4a000 {
+ compatible = "qcom,sc7280-cci", "qcom,msm8996-cci";
+ reg = <0 0x0ac4a000 0 0x1000>;
+ interrupts = ;
+ power-domains = < CAM_CC_TITAN_TOP_GDSC>;
+
+ clocks = < CAM_CC_CAMNOC_AXI_CLK>,
+ < CAM_CC_SLOW_AHB_CLK_SRC>,
+ < CAM_CC_CPAS_AHB_CLK>,
+ < CAM_CC_CCI_0_CLK>,
+ < CAM_CC_CCI_0_CLK_SRC>;
+ clock-names = "camnoc_axi",
+ "slow_ahb_src",
+ "cpas_ahb",
+ "cci",
+ "cci_src";
I guess this is more of a question to e.g. Bryan, but are all of these clocks
actually necessary?
Konrad
Hmm its a good question, we generally take the approach of adopting all of the
downstream clocks for these camera interfaces verbatim.
The clock plan for this part only calls out cci_X_clk and cci_x_clk_src for the
CCI however we know that to be incomplete since we *absolutely* need to have
the AXI for the block clocked to access those registers, same deal with the AHB
bus.
AXI: registers
AHB: data
In the above list the only clock you might conceivably not need is CPAS_AHB_CLK.
Let me zap that clock from sdm845 since I have an rb3 right in front of me and
see what happens.
Crash and reset
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4402,13 +4402,11 @@ cci: cci@ac4a000 {
clocks = <_camcc CAM_CC_CAMNOC_AXI_CLK>,
<_camcc CAM_CC_SOC_AHB_CLK>,
<_camcc CAM_CC_SLOW_AHB_CLK_SRC>,
- <_camcc CAM_CC_CPAS_AHB_CLK>,
<_camcc CAM_CC_CCI_CLK>,
<_camcc CAM_CC_CCI_CLK_SRC>;
clock-names = "camnoc_axi",
"soc_ahb",
"slow_ahb_src",
- "cpas_ahb",
"cci",
"cci_src";
I think the list is good tbh
WDYT about camcc consuming ahb, like dispcc does?
AXI, hmm.. not quite sure what to do with it
Konrad
Hmm on which platform, camcc clock depds on sdm845 looks very sparse to me.
8550 OTOH
dispcc: clock-controller@af0 {
compatible = "qcom,sm8550-dispcc";
reg = <0 0x0af0 0 0x2>;
clocks = <_tcxo_div2>,
<_tcxo_ao_div2>,
< GCC_DISP_AHB_CLK>,
videocc: clock-controller@aaf {
compatible = "qcom,sm8550-videocc";
reg = <0 0x0aaf 0 0x1>;
clocks = <_tcxo_div2>,
< GCC_VIDEO_AHB_CLK>;
sm8250
camcc: clock-controller@ad0 {
compatible = "qcom,sm8250-camcc";
reg = <0 0x0ad0 0 0x1>;
clocks = < GCC_CAMERA_AHB_CLK>,
I think those DISP_AHB, VIDEO_AHB_CLK, CAMERA_AHB_CLKs should live in
the display, video and camss blocks i.e. they are not clocks that you
require to access the clock controller registers themselves...
I'm seeing for the most part these MEDIAIPBLOCK_AHB_CLKs don't come from
the GCC AHB clock but from another root clock generator.
bi_tcxo ->
cam_cc_pll0_out_main ->
cam_cc_pll0_out_even ->
cam_cc_pll0_out_odd ->
cam_cc_pll2_out_main ->
cam_cc_slow_ahb_clk_src ->
camcc_bps_ahb_clk
camcc_ipe_0_ahb_clk
...
camcc_core_ahb_clk
Lets see what happens to sm8250 if we remove CAMERA_AHB_CLK from the
camera clock controller @ camcc: clock-controller@ad0 {} I don't
believe that is required.
...
Yep.. does SFA
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 1efa07f2caff4..1e7d9ee25eeae 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -4172,11 +4172,10 @@ port@5 {
camcc: clock-controller@ad0 {
compatible = "qcom,sm8250-camcc";
reg = <0 0x0ad0 0 0x1>;
- clocks = < GCC_CAMERA_AHB_CLK>,
-
Re: [PATCH] tracing: relax trace_event_eval_update() execution with schedule()
On 29/09/2023 17:06, Steven Rostedt wrote: > On Fri, 29 Sep 2023 16:13:48 +0200 > Clément Léger wrote: > >> When kernel is compiled without preemption, the eval_map_work_func() >> (which calls trace_event_eval_update()) will not be preempted up to its >> complete execution. This can actually cause a problem since if another >> CPU call stop_machine(), the call will have to wait for the >> eval_map_work_func() function to finish executing in the workqueue >> before being able to be scheduled. This problem was observe on a SMP >> system at boot time, when the CPU calling the initcalls executed >> clocksource_done_booting() which in the end calls stop_machine(). We >> observed a 1 second delay because one CPU was executing >> eval_map_work_func() and was not preempted by the stop_machine() task. >> >> Adding a call to schedule() in trace_event_eval_update() allows to let >> other tasks to be executed and thus continue working asynchronously like >> before without blocking any pending task at boot time. >> >> Signed-off-by: Clément Léger >> --- >> kernel/trace/trace_events.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c >> index 91951d038ba4..dbdf57a081c0 100644 >> --- a/kernel/trace/trace_events.c >> +++ b/kernel/trace/trace_events.c >> @@ -2770,6 +2770,7 @@ void trace_event_eval_update(struct trace_eval_map >> **map, int len) >> update_event_fields(call, map[i]); >> } >> } >> +schedule(); > > The proper answer to this is "cond_resched()" but still, there's going > to be work to get rid of all that soon [1]. But I'll take a cond_resched() > now until that is implemented. Hi Steven, Thanks for the information, I'll update the patch and send a V2. Clément > > -- Steve > >> } >> up_write(_event_sem); >> } > > [1] https://lore.kernel.org/all/87cyyfxd4k.ffs@tglx/
Re: [PATCH] tracing: relax trace_event_eval_update() execution with schedule()
On Fri, 29 Sep 2023 16:13:48 +0200 Clément Léger wrote: > When kernel is compiled without preemption, the eval_map_work_func() > (which calls trace_event_eval_update()) will not be preempted up to its > complete execution. This can actually cause a problem since if another > CPU call stop_machine(), the call will have to wait for the > eval_map_work_func() function to finish executing in the workqueue > before being able to be scheduled. This problem was observe on a SMP > system at boot time, when the CPU calling the initcalls executed > clocksource_done_booting() which in the end calls stop_machine(). We > observed a 1 second delay because one CPU was executing > eval_map_work_func() and was not preempted by the stop_machine() task. > > Adding a call to schedule() in trace_event_eval_update() allows to let > other tasks to be executed and thus continue working asynchronously like > before without blocking any pending task at boot time. > > Signed-off-by: Clément Léger > --- > kernel/trace/trace_events.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c > index 91951d038ba4..dbdf57a081c0 100644 > --- a/kernel/trace/trace_events.c > +++ b/kernel/trace/trace_events.c > @@ -2770,6 +2770,7 @@ void trace_event_eval_update(struct trace_eval_map > **map, int len) > update_event_fields(call, map[i]); > } > } > + schedule(); The proper answer to this is "cond_resched()" but still, there's going to be work to get rid of all that soon [1]. But I'll take a cond_resched() now until that is implemented. -- Steve > } > up_write(_event_sem); > } [1] https://lore.kernel.org/all/87cyyfxd4k.ffs@tglx/
Re: [PATCH v5 09/18] x86/sgx: Store struct sgx_encl when allocating new VA pages
On Wed, 27 Sep 2023 16:21:19 -0500, Huang, Kai wrote:
On Wed, 2023-09-27 at 10:35 -0500, Haitao Huang wrote:
> > +
> > + /* Possible owner types */
> > + union {
> > + struct sgx_encl_page *encl_page;
> > + struct sgx_encl *encl;
> > + };
>
> Sadly for virtual EPC page the owner is set to the 'sgx_vepc'
instance it
> belongs to.
>
> Given how sgx_{alloc|free}_epc_page() arbitrarily uses encl_page,>
perhaps we
> should do below?
>
>union {
>struct sgx_encl_page *encl_page;
>struct sgx_encl *encl;
>struct sgx_vepc *vepc;
>void *owner;
>};
>
> And in sgx_{alloc|free}_epc_page() we can use 'owner' instead.
>
As I mentioned in cover letter and change log in 11/18, this series does
not track virtual EPC.
It's not about how does the cover letter says. We cannot ignore the
fact that
currently virtual EPC uses owner too.
But given the virtual EPC code currently doesn't use the owner, I can
live with
not having the 'vepc' member in the union now.
Ah, I forgot even though we don't use the owner field assigned by vepc, it
is still passed into sgx_alloc/free_epc_page().
Will add back "void* owner" and use it for assignment inside
sgx_alloc/free_epc_page().
Thanks
Haitao
[PATCH V3] tracing/timerlat: Hotplug support for the user-space interface
The osnoise/per_cpu/CPU$/timerlat_fd is create for each possible
CPU, but it might create confusion if the CPU is not online.
Create the file only for online CPUs, also follow hotplug by
creating and deleting as CPUs come and go.
Fixes: e88ed227f639 ("tracing/timerlat: Add user-space interface")
Signed-off-by: Daniel Bristot de Oliveira
---
Changes from V2:
- Better split the code into the generic (per_cpu/cpu$)
and timerlat (/timerlat_fd) specific function (Daniel)
- Fixed a cpus_read_lock/unlock() usage (kbuild test)
Link:
https://lore.kernel.org/lkml/6b9a5f306e488bc77bf8521faeade420a0adf3e4.1695224204.git.bris...@kernel.org/
Changes from V1:
- Fix compilation issue when !HOTPLUG
- Fix init interface | hotplug race
Link:
https://lore.kernel.org/lkml/b619d9fd08a3bb47018cf40afa95783844a3c1fd.1694789910.git.bris...@kernel.org/
kernel/trace/trace_osnoise.c | 149 ---
1 file changed, 121 insertions(+), 28 deletions(-)
diff --git a/kernel/trace/trace_osnoise.c b/kernel/trace/trace_osnoise.c
index bd0d01d00fb9..f375fb1e721d 100644
--- a/kernel/trace/trace_osnoise.c
+++ b/kernel/trace/trace_osnoise.c
@@ -229,6 +229,19 @@ static inline struct osnoise_variables
*this_cpu_osn_var(void)
}
#ifdef CONFIG_TIMERLAT_TRACER
+
+/*
+ * osnoise/per_cpu dir
+ */
+static struct dentry *osnoise_per_cpu_fd;
+
+struct osnoise_per_cpu_dir {
+ struct dentry *root;
+ struct dentry *timerlat_fd;
+};
+
+static DEFINE_PER_CPU(struct osnoise_per_cpu_dir, osnoise_per_cpu_dir);
+
/*
* Runtime information for the timer mode.
*/
@@ -2000,6 +2013,9 @@ static int start_kthread(unsigned int cpu)
char comm[24];
if (timerlat_enabled()) {
+ if (!test_bit(OSN_WORKLOAD, _options))
+ return 0;
+
snprintf(comm, 24, "timerlat/%d", cpu);
main = timerlat_main;
} else {
@@ -2065,19 +2081,99 @@ static int start_per_cpu_kthreads(void)
return retval;
}
+#ifdef CONFIG_TIMERLAT_TRACER
+static struct dentry *osnoise_get_per_cpu_dir(long cpu)
+{
+ struct dentry *cpu_dir_entry = per_cpu_ptr(_per_cpu_dir,
cpu)->root;
+ char cpu_str[30]; /* see trace.c: tracing_init_tracefs_percpu() */
+
+ if (cpu_dir_entry)
+ return cpu_dir_entry;
+
+ if (!osnoise_per_cpu_fd)
+ return NULL;
+
+ snprintf(cpu_str, 30, "cpu%ld", cpu);
+ cpu_dir_entry = tracefs_create_dir(cpu_str, osnoise_per_cpu_fd);
+ if (!cpu_dir_entry)
+ return NULL;
+
+ per_cpu_ptr(_per_cpu_dir, cpu)->root = cpu_dir_entry;
+
+ return cpu_dir_entry;
+}
+
+static void osnoise_put_per_cpu_dir(long cpu)
+{
+ struct dentry *cpu_dir_entry = per_cpu_ptr(_per_cpu_dir,
cpu)->root;
+
+ if (!cpu_dir_entry)
+ return;
+
+ tracefs_remove(cpu_dir_entry);
+
+ per_cpu_ptr(_per_cpu_dir, cpu)->root = NULL;
+}
+
+static const struct file_operations timerlat_fd_fops;
+
+static int timerlat_add_per_cpu_interface(long cpu)
+{
+ struct dentry *cpu_dir_entry = osnoise_get_per_cpu_dir(cpu);
+ struct dentry *timerlat_fd;
+
+ lockdep_assert_cpus_held();
+
+ if (!cpu_dir_entry)
+ return -ENOMEM;
+
+ timerlat_fd = trace_create_file("timerlat_fd", TRACE_MODE_READ,
cpu_dir_entry, NULL,
+ _fd_fops);
+ if (!timerlat_fd)
+ goto out_put;
+
+ per_cpu_ptr(_per_cpu_dir, cpu)->timerlat_fd = timerlat_fd;
+
+ /* Record the CPU */
+ d_inode(timerlat_fd)->i_cdev = (void *)(cpu);
+
+ return 0;
+
+out_put:
+ osnoise_put_per_cpu_dir(cpu);
+ return -ENOMEM;
+}
+
+static void timerlat_rm_per_cpu_interface(long cpu)
+{
+ struct dentry *timerlat_fd = per_cpu_ptr(_per_cpu_dir,
cpu)->timerlat_fd;
+
+ if (timerlat_fd) {
+ tracefs_remove(timerlat_fd);
+ per_cpu_ptr(_per_cpu_dir, cpu)->timerlat_fd = NULL;
+ }
+
+ osnoise_put_per_cpu_dir(cpu);
+}
+#elif defined(CONFIG_HOTPLUG_CPU)
+static int timerlat_add_per_cpu_interface(long cpu) { return 0; };
+static void timerlat_rm_per_cpu_interface(long cpu) {};
+#endif
+
#ifdef CONFIG_HOTPLUG_CPU
static void osnoise_hotplug_workfn(struct work_struct *dummy)
{
unsigned int cpu = smp_processor_id();
mutex_lock(_types_lock);
-
- if (!osnoise_has_registered_instances())
- goto out_unlock_trace;
-
mutex_lock(_lock);
cpus_read_lock();
+ timerlat_add_per_cpu_interface(cpu);
+
+ if (!osnoise_has_registered_instances())
+ goto out_unlock;
+
if (!cpumask_test_cpu(cpu, _cpumask))
goto out_unlock;
@@ -2086,7 +2182,6 @@ static void osnoise_hotplug_workfn(struct work_struct
*dummy)
out_unlock:
cpus_read_unlock();
mutex_unlock(_lock);
-out_unlock_trace:
mutex_unlock(_types_lock);
}
@@
[ANNOUNCE] kmod 31
kmod 30 is out:
https://www.kernel.org/pub/linux/utils/kernel/kmod/kmod-31.tar.xz
https://www.kernel.org/pub/linux/utils/kernel/kmod/kmod-31.tar.sign
Improvements
- Allow passing a path to modprobe so the module is loaded from
anywhere from the filesystem, but still handling the module
dependencies recorded in the indexes. This is mostly intended for
kernel
developers to speedup testing their kernel modules without having to
load the
dependencies manually or override the module in /usr/lib/modules/.
Now it's possible to do:
# modprobe ./drivers/gpu/drm/i915/i915.ko
As long as the dependencies didn't change, this should do the right
thing
- Use in-kernel decompression if available. This will check the runtime
support
in the kernel for decompressing modules and use it through
finit_module().
Previously kmod would fallback to the older init_module() when using
compressed modules since there wasn't a way to instruct the kernel to
uncompress it on load or check if the kernel supported it or not.
This requires a recent kernel (>= 6.4) to have that support and
in-kernel decompression properly working in the kernel.
- Make modprobe fallback to syslog when stderr is not available, as was
documented in the man page, but not implemented
- Better explaing `modprobe -r` and how it differentiates from rmmod
- depmod learned a `-o ` option to allow using a separate output
directory. With this, it's possible to split the output files from
the ones used as input from the kernel build system
- Add compat with glibc >= 2.32.9000 that dropped __xstat
- Improve testsuite to stop skipping tests when sysconfdir is something
other than /etc
- Build system improvements and updates
- Change a few return codes from -ENOENT to -ENODATA to avoid confusing
output
in depmod when the module itself lacks a particular ELF section due
to e.g.
CONFIG_MODVERSIONS=n in the kernel.
Bug Fixes
- Fix testsuite using uninitialized memory when testing module removal
with --wait
- Fix testsuite not correctly overriding the stat syscall on 32-bit
platforms. For most architectures this was harmless, but for MIPS it
was causing some tests to fail.
- Fix handling unknown signature algorithm
- Fix linking with a static liblzma, libzstd or zlib
- Fix memory leak when removing module holders
- Fix out-of-bounds access when using very long paths as argument to
rmmod
- Fix warnings reported by UBSan
Shortlog is below:
Adam Gołębiowski (1):
autogen.sh: remove --with-rootprefix, it is gone since kmod-11
Dimitri John Ledkov (1):
build: enable building & running tests from a subdir
Dmitry Antipov (3):
libkmod, depmod: prefer -ENODATA over -ENOENT if no section found
libkmod: fix possible out-of-bounds memory access
shared: avoid passing {NULL, 0} array to bsearch()
Emil Velikov (10):
depmod: Introduce outdir option
treewide: add some static const notations
testsuite: add function declarations for __xstat family
testsuite/depmod: use defines for the rootfs/lib_modules
libkmod: error out on unknown hash algorithm
libkmod: remove unused kmod_module_get_builtin
libkmod: annotate kmod_builtin_iter API as static
shared: annotate local API as static
configure: manage libkmod.pc.in and version.py.in via AC_CONFIG_FILES
libkmod: add fallback MODULE_INIT_COMPRESSED_FILE define
Fabrice Fontaine (1):
configure.ac: fix link with -llzma
Florian Weimer (1):
kmod: configure.ac: In _Noreturn check, include for exit
Gustavo Sousa (3):
testsuite: Wrap chdir()
modprobe: Move insertion block into separate function
modprobe: Allow passing path to module
Jan Engelhardt (1):
testsuite: repair read of uninitialized memory
Julien Cristau (1):
testsuite: fix override of `stat` on 32-bit architectures
Lucas De Marchi (8):
testsuite: Move setup-rootfs logic from Makefile to script
testsuite: Handle different sysconfdir
libkmod: Do not inititialize file->memory on open
libkmod: Extract finit_module vs init_module paths
libkmod: Keep track of compression type
libkmod: Keep track of in-kernel compression support
libkmod: Use kernel decompression when available
kmod 31
Mikhail Novosyolov (1):
libkmod: do not crash on unknown signature algorithm
Nicolas Schier (1):
modprobe: rmmod_do_module: Free kmod list of holders
Quentin Armitage (1):
modprobe: Write error messages to syslog if stderr is unavailable
Yauheni Kaliuta (1):
man/rmmod: explain why modprobe -r is more useful
Thank y'all
Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control Interface busses
On 29.09.2023 16:15, Bryan O'Donoghue wrote:
> On 29/09/2023 14:35, Konrad Dybcio wrote:
>>
>>
>> On 9/29/23 10:01, Luca Weiss wrote:
>>> Add the CCI busses found on sc7280 and their pinctrl states.
>>>
>>> Signed-off-by: Luca Weiss
>>> ---
>>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 136
>>> +++
>>> 1 file changed, 136 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> index 66f1eb83cca7..65550de2e4ff 100644
>>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> @@ -3793,6 +3793,86 @@ videocc: clock-controller@aaf {
>>> #power-domain-cells = <1>;
>>> };
>>> + cci0: cci@ac4a000 {
>>> + compatible = "qcom,sc7280-cci", "qcom,msm8996-cci";
>>> + reg = <0 0x0ac4a000 0 0x1000>;
>>> + interrupts = ;
>>> + power-domains = < CAM_CC_TITAN_TOP_GDSC>;
>>> +
>>> + clocks = < CAM_CC_CAMNOC_AXI_CLK>,
>>> + < CAM_CC_SLOW_AHB_CLK_SRC>,
>>> + < CAM_CC_CPAS_AHB_CLK>,
>>> + < CAM_CC_CCI_0_CLK>,
>>> + < CAM_CC_CCI_0_CLK_SRC>;
>>> + clock-names = "camnoc_axi",
>>> + "slow_ahb_src",
>>> + "cpas_ahb",
>>> + "cci",
>>> + "cci_src";
>> I guess this is more of a question to e.g. Bryan, but are all of these
>> clocks actually necessary?
>>
>> Konrad
> Hmm its a good question, we generally take the approach of adopting all of
> the downstream clocks for these camera interfaces verbatim.
>
> The clock plan for this part only calls out cci_X_clk and cci_x_clk_src for
> the CCI however we know that to be incomplete since we *absolutely* need to
> have the AXI for the block clocked to access those registers, same deal with
> the AHB bus.
>
> AXI: registers
> AHB: data
>
> In the above list the only clock you might conceivably not need is
> CPAS_AHB_CLK.
>
> Let me zap that clock from sdm845 since I have an rb3 right in front of me
> and see what happens.
>
> Crash and reset
>
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -4402,13 +4402,11 @@ cci: cci@ac4a000 {
> clocks = <_camcc CAM_CC_CAMNOC_AXI_CLK>,
> <_camcc CAM_CC_SOC_AHB_CLK>,
> <_camcc CAM_CC_SLOW_AHB_CLK_SRC>,
> - <_camcc CAM_CC_CPAS_AHB_CLK>,
> <_camcc CAM_CC_CCI_CLK>,
> <_camcc CAM_CC_CCI_CLK_SRC>;
> clock-names = "camnoc_axi",
> "soc_ahb",
> "slow_ahb_src",
> - "cpas_ahb",
> "cci",
> "cci_src";
>
>
> I think the list is good tbh
WDYT about camcc consuming ahb, like dispcc does?
AXI, hmm.. not quite sure what to do with it
Konrad
Re: [PATCH 1/3] dt-bindings: i2c: qcom-cci: Document SC7280 compatible
On 29/09/2023 09:01, Luca Weiss wrote: Document the compatible for the CCI block found on SC7280 SoC. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml index 042d4dc636ee..158588236749 100644 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml @@ -25,6 +25,7 @@ properties: - items: - enum: + - qcom,sc7280-cci - qcom,sdm845-cci - qcom,sm6350-cci - qcom,sm8250-cci Reviewed-by: Bryan O'Donoghue
Re: [PATCH 1/3] dt-bindings: i2c: qcom-cci: Document SC7280 compatible
On 29/09/2023 09:01, Luca Weiss wrote: Document the compatible for the CCI block found on SC7280 SoC. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml index 042d4dc636ee..158588236749 100644 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml @@ -25,6 +25,7 @@ properties: - items: - enum: + - qcom,sc7280-cci - qcom,sdm845-cci - qcom,sm6350-cci - qcom,sm8250-cci Reviewed-by: Bryan O'Donoghue
Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control Interface busses
On 29/09/2023 14:35, Konrad Dybcio wrote:
On 9/29/23 10:01, Luca Weiss wrote:
Add the CCI busses found on sc7280 and their pinctrl states.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 136
+++
1 file changed, 136 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..65550de2e4ff 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3793,6 +3793,86 @@ videocc: clock-controller@aaf {
#power-domain-cells = <1>;
};
+ cci0: cci@ac4a000 {
+ compatible = "qcom,sc7280-cci", "qcom,msm8996-cci";
+ reg = <0 0x0ac4a000 0 0x1000>;
+ interrupts = ;
+ power-domains = < CAM_CC_TITAN_TOP_GDSC>;
+
+ clocks = < CAM_CC_CAMNOC_AXI_CLK>,
+ < CAM_CC_SLOW_AHB_CLK_SRC>,
+ < CAM_CC_CPAS_AHB_CLK>,
+ < CAM_CC_CCI_0_CLK>,
+ < CAM_CC_CCI_0_CLK_SRC>;
+ clock-names = "camnoc_axi",
+ "slow_ahb_src",
+ "cpas_ahb",
+ "cci",
+ "cci_src";
I guess this is more of a question to e.g. Bryan, but are all of these
clocks actually necessary?
Konrad
Hmm its a good question, we generally take the approach of adopting all
of the downstream clocks for these camera interfaces verbatim.
The clock plan for this part only calls out cci_X_clk and cci_x_clk_src
for the CCI however we know that to be incomplete since we *absolutely*
need to have the AXI for the block clocked to access those registers,
same deal with the AHB bus.
AXI: registers
AHB: data
In the above list the only clock you might conceivably not need is
CPAS_AHB_CLK.
Let me zap that clock from sdm845 since I have an rb3 right in front of
me and see what happens.
Crash and reset
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4402,13 +4402,11 @@ cci: cci@ac4a000 {
clocks = <_camcc CAM_CC_CAMNOC_AXI_CLK>,
<_camcc CAM_CC_SOC_AHB_CLK>,
<_camcc CAM_CC_SLOW_AHB_CLK_SRC>,
- <_camcc CAM_CC_CPAS_AHB_CLK>,
<_camcc CAM_CC_CCI_CLK>,
<_camcc CAM_CC_CCI_CLK_SRC>;
clock-names = "camnoc_axi",
"soc_ahb",
"slow_ahb_src",
- "cpas_ahb",
"cci",
"cci_src";
I think the list is good tbh
Reviewed-by: Bryan O'Donoghue
[PATCH] tracing: relax trace_event_eval_update() execution with schedule()
When kernel is compiled without preemption, the eval_map_work_func() (which calls trace_event_eval_update()) will not be preempted up to its complete execution. This can actually cause a problem since if another CPU call stop_machine(), the call will have to wait for the eval_map_work_func() function to finish executing in the workqueue before being able to be scheduled. This problem was observe on a SMP system at boot time, when the CPU calling the initcalls executed clocksource_done_booting() which in the end calls stop_machine(). We observed a 1 second delay because one CPU was executing eval_map_work_func() and was not preempted by the stop_machine() task. Adding a call to schedule() in trace_event_eval_update() allows to let other tasks to be executed and thus continue working asynchronously like before without blocking any pending task at boot time. Signed-off-by: Clément Léger --- kernel/trace/trace_events.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c index 91951d038ba4..dbdf57a081c0 100644 --- a/kernel/trace/trace_events.c +++ b/kernel/trace/trace_events.c @@ -2770,6 +2770,7 @@ void trace_event_eval_update(struct trace_eval_map **map, int len) update_event_fields(call, map[i]); } } + schedule(); } up_write(_event_sem); } -- 2.40.1
Re: [PATCH 3/3] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable CCI busses
On Fri Sep 29, 2023 at 3:36 PM CEST, Konrad Dybcio wrote: > > > On 9/29/23 10:01, Luca Weiss wrote: > > Enable the CCI busses where sensors are connected to. > > > > Not covered here is the regulator used for pull-up on the I2C busses. > > This would be pm8008_l6 (L6P). > Does it make sense to enable non-functional hw then? Or is it on by default? Without the out-of-tree pm8008 driver you cannot talk to any hardware on the i2c busses there, so.. I guess you have a point? A little bird told me this week they're working on a new revision for pm8008 so hopefully this is coming at some point. > > Konrad
Re: [PATCH 3/3] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable CCI busses
On 9/29/23 10:01, Luca Weiss wrote: Enable the CCI busses where sensors are connected to. Not covered here is the regulator used for pull-up on the I2C busses. This would be pm8008_l6 (L6P). Does it make sense to enable non-functional hw then? Or is it on by default? Konrad
Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control Interface busses
On 9/29/23 10:01, Luca Weiss wrote:
Add the CCI busses found on sc7280 and their pinctrl states.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 136 +++
1 file changed, 136 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..65550de2e4ff 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3793,6 +3793,86 @@ videocc: clock-controller@aaf {
#power-domain-cells = <1>;
};
+ cci0: cci@ac4a000 {
+ compatible = "qcom,sc7280-cci", "qcom,msm8996-cci";
+ reg = <0 0x0ac4a000 0 0x1000>;
+ interrupts = ;
+ power-domains = < CAM_CC_TITAN_TOP_GDSC>;
+
+ clocks = < CAM_CC_CAMNOC_AXI_CLK>,
+< CAM_CC_SLOW_AHB_CLK_SRC>,
+< CAM_CC_CPAS_AHB_CLK>,
+< CAM_CC_CCI_0_CLK>,
+< CAM_CC_CCI_0_CLK_SRC>;
+ clock-names = "camnoc_axi",
+ "slow_ahb_src",
+ "cpas_ahb",
+ "cci",
+ "cci_src";
I guess this is more of a question to e.g. Bryan, but are all of these
clocks actually necessary?
Konrad
Re: [PATCH] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable UFS
On 29.09.2023 11:52, Luca Weiss wrote: > Enable the UFS phy and controller so that we can access the internal > storage of the phone. > > At the same time we need to bump the minimum voltage used for UFS VCC, > otherwise it doesn't initialize properly. The new range is taken from > the vcc-voltage-level property downstream. > > See also the following link for more information about the VCCQ/VCCQ2: > https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/1590a3739e7dc29d2597307881553236d492f188/fp5/yupik-idp-pm7250b.dtsi#207 > > Signed-off-by: Luca Weiss > --- > I'm not 100% convinced about the regulator range change. For sure with > the original voltage range the UFS fails to initialize, but looking at > downstream kernel during runtime (debugfs) we see the VCC voltage > switches between 2.4V (idle?) and 2.952V (active?). But even with this > change in mainline the regulator would always stay at 2.504V which is > for sure lower than the downstream operating voltage of 2.952V. Behavior > wise I don't see a difference between ~2.5V and ~2.9V. > > Should I just constrain the regulator here to min=max=2.952V? Or just > say it's okay as-is? > > Depends on: > https://lore.kernel.org/linux-arm-msm/20230927081858.15961-1-quic_nitir...@quicinc.com/ > --- There's a little funny hack inside the driver #if defined(CONFIG_SCSI_UFSHCD_QTI) if (vreg->low_voltage_sup && !vreg->low_voltage_active && on) min_uV = vreg->max_uV; #endif so, when the ufs is in use, it's pinned to vmax Konrad
Re: [PATCH RFC] ASoC: codecs: aw88261: Remove non-existing reset gpio
On Fri, Sep 29, 2023 at 02:44:47PM +0200, Luca Weiss wrote: > Unfortunately the dt binding is a bit trickier to update since it's made > for both AW88261 and AW88395. > After spending a bit of time using non-Google search machines (Google > seems incapable of finding anything there) I found a datasheet for > AW88395 and that does appear to have a RSTN "Active low hardware reset" > pin so we should not remove that one. > Probably it's easier to separate the two dt bindings then, instead of > trying to keep them together? You can do conditionals based on compatibles so it might not be required. signature.asc Description: PGP signature
[PATCH v2] arm64: dts: qcom: sc7280: Add ports subnodes in usb/dp qmpphy node
Add the USB3+DP Combo QMP PHY port subnodes to facilitate the
description of the connection between the hardware blocks.
Put it in the SoC DTSI to avoid duplication in the device DTs.
Reviewed-by: Konrad Dybcio
Signed-off-by: Luca Weiss
---
Changes in v2:
- Update commit message after feedback from Konrad
- Pick up tags
- Link to v1:
https://lore.kernel.org/r/20230929-sc7280-qmpphy-ports-v1-1-7532c1197...@fairphone.com
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..4e34d00e246b 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3399,6 +3399,32 @@ usb_1_qmpphy: phy@88e8000 {
#clock-cells = <1>;
#phy-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_dp_qmpphy_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_dp_qmpphy_usb_ss_in: endpoint {
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb_dp_qmpphy_dp_in: endpoint {
+ };
+ };
+ };
};
usb_2: usb@8cf8800 {
---
base-commit: df964ce9ef9fea10cf131bf6bad8658fde7956f6
change-id: 20230929-sc7280-qmpphy-ports-20afd4212470
Best regards,
--
Luca Weiss
Re: [PATCH RFC] ASoC: codecs: aw88261: Remove non-existing reset gpio
On Fri Sep 29, 2023 at 2:30 PM CEST, Mark Brown wrote: > On Fri, Sep 29, 2023 at 12:28:10PM +0200, Luca Weiss wrote: > > According to the AW88261 datasheet (V1.1) and device schematics I have > > access to, there is no reset gpio present on the AW88261. Remove it. > > That looks to be the case according to > > > https://doc.awinic.com/doc/20230609wm/c815e155-60b7-40fb-889b-676b02e67d0a.pdf Nice to see the doc is also available there. Seems it only shows up on the site search but not with Google https://www.awinic.com/en/search/all?titleSearch=AW88261 > > (which is v1.5 FWIW), Weidong? > > > In case this looks okay, also to the driver author at Awinic, the > > binding doc also needs to be updated to include this change and not > > require (or even allow) the reset-gpios anymore. > > It would be easier to just send the proper patch to start off with, no > need to resend if the change is confirmed... Unfortunately the dt binding is a bit trickier to update since it's made for both AW88261 and AW88395. After spending a bit of time using non-Google search machines (Google seems incapable of finding anything there) I found a datasheet for AW88395 and that does appear to have a RSTN "Active low hardware reset" pin so we should not remove that one. Probably it's easier to separate the two dt bindings then, instead of trying to keep them together? Regards Luca
Re: [PATCH RFC] ASoC: codecs: aw88261: Remove non-existing reset gpio
On Fri, Sep 29, 2023 at 12:28:10PM +0200, Luca Weiss wrote: > According to the AW88261 datasheet (V1.1) and device schematics I have > access to, there is no reset gpio present on the AW88261. Remove it. That looks to be the case according to https://doc.awinic.com/doc/20230609wm/c815e155-60b7-40fb-889b-676b02e67d0a.pdf (which is v1.5 FWIW), Weidong? > In case this looks okay, also to the driver author at Awinic, the > binding doc also needs to be updated to include this change and not > require (or even allow) the reset-gpios anymore. It would be easier to just send the proper patch to start off with, no need to resend if the change is confirmed... signature.asc Description: PGP signature
Re: [PATCH] arm64: dts: qcom: sc7280: Add ports subnodes in usb/dp qmpphy node
On Fri Sep 29, 2023 at 1:44 PM CEST, Konrad Dybcio wrote: > On 29.09.2023 09:31, Luca Weiss wrote: > > Add the USB3+DP Combo QMP PHY port subnodes in the SC7280 SoC DTSI to > > avoid duplication in the devices DTs. > The rationale here is to make describing the connections between > certain hw blocks possible. Defining it in the soc dtsi gives us > a very cool side-effect of not having to repeat this, but it's not > the main point here Commit message is copy-pasted from sm8550 commit with has your R-b ;) But I'll change it for this commit since your comment makes sense. > > With the commit msg amended: > > Reviewed-by: Konrad Dybcio > > Konrad
Re: [PATCH] arm64: dts: qcom: sc7280: Add ports subnodes in usb/dp qmpphy node
On 29.09.2023 09:31, Luca Weiss wrote: > Add the USB3+DP Combo QMP PHY port subnodes in the SC7280 SoC DTSI to > avoid duplication in the devices DTs. The rationale here is to make describing the connections between certain hw blocks possible. Defining it in the soc dtsi gives us a very cool side-effect of not having to repeat this, but it's not the main point here With the commit msg amended: Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 3/3] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable venus node
On 29.09.2023 10:38, Luca Weiss wrote: > Enable the venus node so that the video encoder/decoder will start > working. > > Signed-off-by: Luca Weiss > --- Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
On 29.09.2023 10:38, Luca Weiss wrote: > If the video-firmware node is present, the venus driver assumes we're on > a non-TZ system. On a system that doesn't use TZ for kickstarting Venus Chrome devices have something running in EL3, so TZ is present, just not the standard qcom one that we've grown to.. love.. Move the video-firmware node to chrome-common.dtsi so > we can use venus on a TZ board. On non-Chrome boards > At the same time let's disable the venus node by default as is custom on > such nodes. I think that's not what you tried to say The contents look good! Konrad
Re: [PATCH 1/3] media: venus: core: Set up secure memory ranges for SC7280
On 29.09.2023 10:38, Luca Weiss wrote: > Not all SC7280 devices ship with ChromeOS firmware. Other devices need > PAS for image authentication. That requires the predefined virtual > address ranges to be passed via scm calls. Define them to enable Venus > on non-CrOS SC7280 devices. > > Signed-off-by: Luca Weiss > --- The media tree (or at least venus) moves quite slugglishly.. But looks like applying just the DT patches (which I expect to get in first) results in a non-platform-killing: [ 25.851120] qcom-venus aa0.video-codec: Adding to iommu group 11 [ 25.851618] qcom-venus aa0.video-codec: non legacy binding [ 25.916562] qcom-venus aa0.video-codec: invalid setting for UC_REGION [ 25.916569] qcom-venus aa0.video-codec: failed to reset venus core [ 25.919000] qcom-venus: probe of aa0.video-codec failed with error -22 So it should be okay either way. Reviewed-by: Konrad Dybcio Konrad
Re: [PATCH] tracing/eprobe: drop unneeded breaks
On Fri, 29 Sep 2023, Masami Hiramatsu wrote:
> On Thu, 28 Sep 2023 12:43:34 +0200
> Julia Lawall wrote:
>
> > Drop break after return.
> >
>
> Good catch! This looks good to me.
>
> Acked-by: Masami Hiramatsu (Google)
>
> And
>
> Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
Thanks. I didn't include that because it's not a bug. But it does break
Coccinelle, which is how I noticed it.
julia
>
> > Signed-off-by: Julia Lawall
> >
> > ---
> > kernel/trace/trace_eprobe.c |5 +
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/kernel/trace/trace_eprobe.c b/kernel/trace/trace_eprobe.c
> > index 72714cbf475c..03c851f57969 100644
> > --- a/kernel/trace/trace_eprobe.c
> > +++ b/kernel/trace/trace_eprobe.c
> > @@ -788,12 +788,9 @@ find_and_get_event(const char *system, const char
> > *event_name)
> > name = trace_event_name(tp_event);
> > if (!name || strcmp(event_name, name))
> > continue;
> > - if (!trace_event_try_get_ref(tp_event)) {
> > + if (!trace_event_try_get_ref(tp_event))
> > return NULL;
> > - break;
> > - }
> > return tp_event;
> > - break;
> > }
> > return NULL;
> > }
> >
>
>
> --
> Masami Hiramatsu (Google)
>
Re: [PATCH] tracing/eprobe: drop unneeded breaks
On Thu, 28 Sep 2023 12:43:34 +0200
Julia Lawall wrote:
> Drop break after return.
>
Good catch! This looks good to me.
Acked-by: Masami Hiramatsu (Google)
And
Fixes: 7491e2c44278 ("tracing: Add a probe that attaches to trace events")
> Signed-off-by: Julia Lawall
>
> ---
> kernel/trace/trace_eprobe.c |5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace_eprobe.c b/kernel/trace/trace_eprobe.c
> index 72714cbf475c..03c851f57969 100644
> --- a/kernel/trace/trace_eprobe.c
> +++ b/kernel/trace/trace_eprobe.c
> @@ -788,12 +788,9 @@ find_and_get_event(const char *system, const char
> *event_name)
> name = trace_event_name(tp_event);
> if (!name || strcmp(event_name, name))
> continue;
> - if (!trace_event_try_get_ref(tp_event)) {
> + if (!trace_event_try_get_ref(tp_event))
> return NULL;
> - break;
> - }
> return tp_event;
> - break;
> }
> return NULL;
> }
>
--
Masami Hiramatsu (Google)
Re: [PATCH v5] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms
On Wed, 27 Sep 2023 17:35:16 + "Alessandro Carminati (Red Hat)" wrote: > It is not uncommon for drivers or modules related to similar peripherals > to have symbols with the exact same name. > While this is not a problem for the kernel's binary itself, it becomes an > issue when attempting to trace or probe specific functions using > infrastructure like ftrace or kprobe. > > The tracing subsystem relies on the `nm -n vmlinux` output, which provides > symbol information from the kernel's ELF binary. However, when multiple > symbols share the same name, the standard nm output does not differentiate > between them. This can lead to confusion and difficulty when trying to > probe the intended symbol. > > ~ # cat /proc/kallsyms | grep " name_show" > 8c4f76d0 t name_show > 8c9cccb0 t name_show > 8cb0ac20 t name_show > 8cc728c0 t name_show > 8ce0efd0 t name_show > 8ce126c0 t name_show > 8ce1dd20 t name_show > 8ce24e70 t name_show > 8d1104c0 t name_show > 8d1fe480 t name_show > > kas_alias addresses this challenge by enhancing symbol names with > meaningful suffixes generated from the source file and line number > during the kernel build process. > These newly generated aliases provide tracers with the ability to > comprehend the symbols they are interacting with when utilizing the > ftracefs interface. > This approach may also allow for the probing by name of previously > inaccessible symbols. > > ~ # cat /proc/kallsyms | grep gic_mask_irq > d15671e505ac t gic_mask_irq > d15671e505ac t gic_mask_irq@drivers_irqchip_irq_gic_c_167 > d15671e532a4 t gic_mask_irq > d15671e532a4 t gic_mask_irq@drivers_irqchip_irq_gic_v3_c_407 > ~ # > > Changes from v1: > - Integrated changes requested by Masami to exclude symbols with prefixes > "_cfi" and "_pfx". > - Introduced a small framework to handle patterns that need to be excluded > from the alias production. > - Excluded other symbols using the framework. > - Introduced the ability to discriminate between text and data symbols. > - Added two new config symbols in this version: CONFIG_KALLSYMS_ALIAS_DATA, > which allows data for data, and CONFIG_KALLSYMS_ALIAS_DATA_ALL, which > excludes all filters and provides an alias for each duplicated symbol. > > https://lore.kernel.org/all/20230711151925.1092080-1-alessandro.carmin...@gmail.com/ > > Changes from v2: > - Alias tags are created by querying DWARF information from the vmlinux. > - The filename + line number is normalized and appended to the original > name. > - The tag begins with '@' to indicate the symbol source. > - Not a change, but worth mentioning, since the alias is added to the > existing list, the old duplicated name is preserved, and the livepatch > way of dealing with duplicates is maintained. > - Acknowledging the existence of scenarios where inlined functions > declared in header files may result in multiple copies due to compiler > behavior, though it is not actionable as it does not pose an operational > issue. > - Highlighting a single exception where the same name refers to different > functions: the case of "compat_binfmt_elf.c," which directly includes > "binfmt_elf.c" producing identical function copies in two separate > modules. > > https://lore.kernel.org/all/20230714150326.1152359-1-alessandro.carmin...@gmail.com/ > > Changes from v3: > - kas_alias was rewritten in Python to create a more concise and > maintainable codebase. > - The previous automation process used by kas_alias to locate the vmlinux > and the addr2line has been replaced with an explicit command-line switch > for specifying these requirements. > - addr2line has been added into the main Makefile. > - A new command-line switch has been introduced, enabling users to extend > the alias to global data names. > > https://lore.kernel.org/all/20230828080423.3539686-1-alessandro.carmin...@gmail.com/ > > Changes from v4: > - Fixed the O= build issue > - The tool halts execution upon encountering major issues, thereby ensuring > the pipeline is interrupted. > - A cmdline option to specify the source directory added. > - Minor code adjusments. > - Tested on mips32 and i386 > > https://lore.kernel.org/all/20230919193948.465340-1-alessandro.carmin...@gmail.com/ > > NOTE: > About the symbols name duplication that happens as consequence of the > inclusion compat_binfmt_elf.c does, it is evident that this corner is > inherently challenging the addr2line approach. > Attempting to conceal this limitation would be counterproductive. > > compat_binfmt_elf.c includes directly binfmt_elf.c, addr2line can't help > but report all functions and data declared by that file, coming from > binfmt_elf.c. > > My position is that, rather than producing a more complicated pipeline > to handle this corner case, it is better to fix the compat_binfmt_elf.c > anomaly. > > This patch does not deal with the
[PATCH RFC] ASoC: codecs: aw88261: Remove non-existing reset gpio
According to the AW88261 datasheet (V1.1) and device schematics I have
access to, there is no reset gpio present on the AW88261. Remove it.
Signed-off-by: Luca Weiss
---
In case this looks okay, also to the driver author at Awinic, the
binding doc also needs to be updated to include this change and not
require (or even allow) the reset-gpios anymore.
Therefore this is marked RFC for now.
---
sound/soc/codecs/aw88261.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/sound/soc/codecs/aw88261.c b/sound/soc/codecs/aw88261.c
index 45eaf931a69c..e7683f70c2ef 100644
--- a/sound/soc/codecs/aw88261.c
+++ b/sound/soc/codecs/aw88261.c
@@ -10,7 +10,6 @@
#include
#include
-#include
#include
#include
#include "aw88261.h"
@@ -1175,14 +1174,6 @@ static const struct snd_soc_component_driver
soc_codec_dev_aw88261 = {
.remove = aw88261_codec_remove,
};
-static void aw88261_hw_reset(struct aw88261 *aw88261)
-{
- gpiod_set_value_cansleep(aw88261->reset_gpio, 0);
- usleep_range(AW88261_1000_US, AW88261_1000_US + 10);
- gpiod_set_value_cansleep(aw88261->reset_gpio, 1);
- usleep_range(AW88261_1000_US, AW88261_1000_US + 10);
-}
-
static void aw88261_parse_channel_dt(struct aw88261 *aw88261)
{
struct aw_device *aw_dev = aw88261->aw_pa;
@@ -1254,12 +1245,6 @@ static int aw88261_i2c_probe(struct i2c_client *i2c)
i2c_set_clientdata(i2c, aw88261);
- aw88261->reset_gpio = devm_gpiod_get_optional(>dev, "reset",
GPIOD_OUT_LOW);
- if (IS_ERR(aw88261->reset_gpio))
- dev_info(>dev, "reset gpio not defined\n");
- else
- aw88261_hw_reset(aw88261);
-
aw88261->regmap = devm_regmap_init_i2c(i2c, _remap_config);
if (IS_ERR(aw88261->regmap)) {
ret = PTR_ERR(aw88261->regmap);
---
base-commit: b216fb8946f819cf1b63dc12c7867cc501bda57e
change-id: 20230929-aw88261-reset-7e00d9e25952
Best regards,
--
Luca Weiss
[PATCH] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable UFS
Enable the UFS phy and controller so that we can access the internal
storage of the phone.
At the same time we need to bump the minimum voltage used for UFS VCC,
otherwise it doesn't initialize properly. The new range is taken from
the vcc-voltage-level property downstream.
See also the following link for more information about the VCCQ/VCCQ2:
https://gerrit-public.fairphone.software/plugins/gitiles/kernel/msm-extra/devicetree/+/1590a3739e7dc29d2597307881553236d492f188/fp5/yupik-idp-pm7250b.dtsi#207
Signed-off-by: Luca Weiss
---
I'm not 100% convinced about the regulator range change. For sure with
the original voltage range the UFS fails to initialize, but looking at
downstream kernel during runtime (debugfs) we see the VCC voltage
switches between 2.4V (idle?) and 2.952V (active?). But even with this
change in mainline the regulator would always stay at 2.504V which is
for sure lower than the downstream operating voltage of 2.952V. Behavior
wise I don't see a difference between ~2.5V and ~2.9V.
Should I just constrain the regulator here to min=max=2.952V? Or just
say it's okay as-is?
Depends on:
https://lore.kernel.org/linux-arm-msm/20230927081858.15961-1-quic_nitir...@quicinc.com/
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 27 --
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 2de0b8c26c35..fea7639fc0bc 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -182,8 +182,9 @@ vreg_l6b: ldo6 {
};
vreg_l7b: ldo7 {
- regulator-min-microvolt = <240>;
- regulator-max-microvolt = <3544000>;
+ /* Constrained for UFS VCC */
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2952000>;
regulator-initial-mode = ;
};
@@ -632,6 +633,28 @@ bluetooth: bluetooth {
};
};
+_mem_hc {
+ reset-gpios = < 175 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <_l7b>;
+ vcc-max-microamp = <80>;
+ /*
+* Technically l9b enables an eLDO (supplied by s1b) which then powers
+* VCCQ2 of the UFS.
+*/
+ vccq-supply = <_l9b>;
+ vccq-max-microamp = <90>;
+
+ status = "okay";
+};
+
+_mem_phy {
+ vdda-phy-supply = <_l10c>;
+ vdda-pll-supply = <_l6b>;
+
+ status = "okay";
+};
+
_1 {
status = "okay";
};
---
base-commit: d85348daa4407216e47198ed35a43a66883edab6
change-id: 20230929-fp5-ufs-e2c0e21a0142
Best regards,
--
Luca Weiss
Re: [PATCH 3/3] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable venus node
On 29/09/2023 09:38, Luca Weiss wrote:
Enable the venus node so that the video encoder/decoder will start
working.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 2de0b8c26c35..d29f10f822c9 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -665,3 +665,8 @@ _1_qmpphy {
status = "okay";
};
+
+ {
+ firmware-name = "qcom/qcm6490/fairphone5/venus.mbn";
+ status = "okay";
+};
Reviewed-by: Bryan O'Donoghue
Re: [PATCH 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
On 29/09/2023 09:38, Luca Weiss wrote:
If the video-firmware node is present, the venus driver assumes we're on
a non-TZ system. Move the video-firmware node to chrome-common.dtsi so
we can use venus on a TZ board.
At the same time let's disable the venus node by default as is custom on
such nodes.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 8
arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
index 5d462ae14ba1..cd491e4d 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
@@ -104,6 +104,14 @@ {
dma-coherent;
};
+ {
+ status = "okay";
+
+ video-firmware {
+ iommus = <_smmu 0x21a2 0x0>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..fa53f54d4675 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3740,6 +3740,8 @@ venus: video-codec@aa0 {
<_smmu 0x2184 0x20>;
memory-region = <_mem>;
+ status = "disabled";
+
video-decoder {
compatible = "venus-decoder";
};
@@ -3748,10 +3750,6 @@ video-encoder {
compatible = "venus-encoder";
};
- video-firmware {
- iommus = <_smmu 0x21a2 0x0>;
- };
-
venus_opp_table: opp-table {
compatible = "operating-points-v2";
Reviewed-by: Bryan O'Donoghue
Re: [PATCH 1/3] media: venus: core: Set up secure memory ranges for SC7280
On 29/09/2023 09:38, Luca Weiss wrote:
Not all SC7280 devices ship with ChromeOS firmware. Other devices need
PAS for image authentication. That requires the predefined virtual
address ranges to be passed via scm calls. Define them to enable Venus
on non-CrOS SC7280 devices.
Signed-off-by: Luca Weiss
---
drivers/media/platform/qcom/venus/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 054b8e74ba4f..5c6baa0f4d45 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -881,6 +881,10 @@ static const struct venus_resources sc7280_res = {
.vmem_size = 0,
.vmem_addr = 0,
.dma_mask = 0xe000 - 1,
+ .cp_start = 0,
+ .cp_size = 0x2580,
+ .cp_nonpixel_start = 0x100,
+ .cp_nonpixel_size = 0x2480,
.fwname = "qcom/vpu-2.0/venus.mbn",
};
Reviewed-by: Bryan O'Donoghue
[PATCH 2/3] arm64: dts: qcom: sc7280: Move video-firmware to chrome-common
If the video-firmware node is present, the venus driver assumes we're on
a non-TZ system. Move the video-firmware node to chrome-common.dtsi so
we can use venus on a TZ board.
At the same time let's disable the venus node by default as is custom on
such nodes.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 8
arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
index 5d462ae14ba1..cd491e4d 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
@@ -104,6 +104,14 @@ {
dma-coherent;
};
+ {
+ status = "okay";
+
+ video-firmware {
+ iommus = <_smmu 0x21a2 0x0>;
+ };
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..fa53f54d4675 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3740,6 +3740,8 @@ venus: video-codec@aa0 {
<_smmu 0x2184 0x20>;
memory-region = <_mem>;
+ status = "disabled";
+
video-decoder {
compatible = "venus-decoder";
};
@@ -3748,10 +3750,6 @@ video-encoder {
compatible = "venus-encoder";
};
- video-firmware {
- iommus = <_smmu 0x21a2 0x0>;
- };
-
venus_opp_table: opp-table {
compatible = "operating-points-v2";
--
2.42.0
[PATCH 3/3] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable venus node
Enable the venus node so that the video encoder/decoder will start
working.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index 2de0b8c26c35..d29f10f822c9 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -665,3 +665,8 @@ _1_qmpphy {
status = "okay";
};
+
+ {
+ firmware-name = "qcom/qcm6490/fairphone5/venus.mbn";
+ status = "okay";
+};
--
2.42.0
[PATCH 0/3] Enable venus on Fairphone 5 / non-ChromeOS sc7280 venus support
Devices with Qualcomm firmware (compared to ChromeOS firmware) need some changes in the venus driver and dts layout so that venus can initialize. Do these changes, similar to sc7180. Signed-off-by: Luca Weiss --- Luca Weiss (3): media: venus: core: Set up secure memory ranges for SC7280 arm64: dts: qcom: sc7280: Move video-firmware to chrome-common arm64: dts: qcom: qcm6490-fairphone-fp5: Enable venus node arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 5 + arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 8 arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 ++ drivers/media/platform/qcom/venus/core.c | 4 4 files changed, 19 insertions(+), 4 deletions(-) --- base-commit: df964ce9ef9fea10cf131bf6bad8658fde7956f6 change-id: 20230929-sc7280-venus-pas-ea9630525753 Best regards, -- Luca Weiss
[PATCH 1/3] media: venus: core: Set up secure memory ranges for SC7280
Not all SC7280 devices ship with ChromeOS firmware. Other devices need
PAS for image authentication. That requires the predefined virtual
address ranges to be passed via scm calls. Define them to enable Venus
on non-CrOS SC7280 devices.
Signed-off-by: Luca Weiss
---
drivers/media/platform/qcom/venus/core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 054b8e74ba4f..5c6baa0f4d45 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -881,6 +881,10 @@ static const struct venus_resources sc7280_res = {
.vmem_size = 0,
.vmem_addr = 0,
.dma_mask = 0xe000 - 1,
+ .cp_start = 0,
+ .cp_size = 0x2580,
+ .cp_nonpixel_start = 0x100,
+ .cp_nonpixel_size = 0x2480,
.fwname = "qcom/vpu-2.0/venus.mbn",
};
--
2.42.0
[PATCH 2/2] arm64: dts: qcom: pm7250b: Use correct node name for gpios
Use gpio@ instead of pinctrl@ as that's the name expected by the
qcom,spmi-pmic.yaml schema. Update it to fix dt validation.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/pm7250b.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
index df0afe82f250..3bf7cf5d1700 100644
--- a/arch/arm64/boot/dts/qcom/pm7250b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm7250b.dtsi
@@ -148,7 +148,7 @@ pm7250b_adc_tm: adc-tm@3500 {
status = "disabled";
};
- pm7250b_gpios: pinctrl@c000 {
+ pm7250b_gpios: gpio@c000 {
compatible = "qcom,pm7250b-gpio", "qcom,spmi-gpio";
reg = <0xc000>;
gpio-controller;
--
2.42.0
[PATCH 1/2] dt-bindings: mfd: qcom,spmi-pmic: Update gpio example
As per commit ea25d61b448a ("arm64: dts: qcom: Use plural _gpios node
label for PMIC gpios") all dts files now use the plural _gpios instead
of the singular _gpio as label. Update the schema example also to match.
Signed-off-by: Luca Weiss
---
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
index 55e931ba5b47..e4842e1fbd65 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
@@ -245,7 +245,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
-pmi8998_gpio: gpio@c000 {
+pmi8998_gpios: gpio@c000 {
compatible = "qcom,pmi8998-gpio", "qcom,spmi-gpio";
reg = <0xc000>;
gpio-controller;
@@ -330,7 +330,7 @@ examples:
};
};
-pm6150_gpio: gpio@c000 {
+pm6150_gpios: gpio@c000 {
compatible = "qcom,pm6150-gpio", "qcom,spmi-gpio";
reg = <0xc000>;
gpio-controller;
--
2.42.0
[PATCH 0/2] Small updates / fixups for PMIC spmi-gpio
Update the schema to use plural _gpios label in the example. And fix a dtbs_check warning in pm7250b.dtsi. Signed-off-by: Luca Weiss --- Luca Weiss (2): dt-bindings: mfd: qcom,spmi-pmic: Update gpio example arm64: dts: qcom: pm7250b: Use correct node name for gpios Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++-- arch/arm64/boot/dts/qcom/pm7250b.dtsi | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) --- base-commit: df964ce9ef9fea10cf131bf6bad8658fde7956f6 change-id: 20230929-pm7250b-gpio-fixup-f407ee98425a Best regards, -- Luca Weiss
[PATCH 2/3] arm64: dts: qcom: sc7280: Add Camera Control Interface busses
Add the CCI busses found on sc7280 and their pinctrl states.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 136 +++
1 file changed, 136 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..65550de2e4ff 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3793,6 +3793,86 @@ videocc: clock-controller@aaf {
#power-domain-cells = <1>;
};
+ cci0: cci@ac4a000 {
+ compatible = "qcom,sc7280-cci", "qcom,msm8996-cci";
+ reg = <0 0x0ac4a000 0 0x1000>;
+ interrupts = ;
+ power-domains = < CAM_CC_TITAN_TOP_GDSC>;
+
+ clocks = < CAM_CC_CAMNOC_AXI_CLK>,
+< CAM_CC_SLOW_AHB_CLK_SRC>,
+< CAM_CC_CPAS_AHB_CLK>,
+< CAM_CC_CCI_0_CLK>,
+< CAM_CC_CCI_0_CLK_SRC>;
+ clock-names = "camnoc_axi",
+ "slow_ahb_src",
+ "cpas_ahb",
+ "cci",
+ "cci_src";
+ pinctrl-0 = <_default _default>;
+ pinctrl-1 = <_sleep _sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci0_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci0_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ cci1: cci@ac4b000 {
+ compatible = "qcom,sc7280-cci", "qcom,msm8996-cci";
+ reg = <0 0x0ac4b000 0 0x1000>;
+ interrupts = ;
+ power-domains = < CAM_CC_TITAN_TOP_GDSC>;
+
+ clocks = < CAM_CC_CAMNOC_AXI_CLK>,
+< CAM_CC_SLOW_AHB_CLK_SRC>,
+< CAM_CC_CPAS_AHB_CLK>,
+< CAM_CC_CCI_1_CLK>,
+< CAM_CC_CCI_1_CLK_SRC>;
+ clock-names = "camnoc_axi",
+ "slow_ahb_src",
+ "cpas_ahb",
+ "cci",
+ "cci_src";
+ pinctrl-0 = <_default _default>;
+ pinctrl-1 = <_sleep _sleep>;
+ pinctrl-names = "default", "sleep";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+
+ cci1_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ cci1_i2c1: i2c-bus@1 {
+ reg = <1>;
+ clock-frequency = <100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
camcc: clock-controller@ad0 {
compatible = "qcom,sc7280-camcc";
reg = <0 0x0ad0 0 0x1>;
@@ -4298,6 +4378,62 @@ tlmm: pinctrl@f10 {
gpio-ranges = < 0 0 175>;
wakeup-parent = <>;
+ cci0_default: cci0-default-state {
+ pins = "gpio69", "gpio70";
+ function = "cci_i2c";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ cci0_sleep: cci0-sleep-state {
+ pins = "gpio69", "gpio70";
+ function = "cci_i2c";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ cci1_default: cci1-default-state {
+ pins = "gpio71",
[PATCH 3/3] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable CCI busses
Enable the CCI busses where sensors are connected to.
Not covered here is the regulator used for pull-up on the I2C busses.
This would be pm8008_l6 (L6P).
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
index c8e7e6689b20..3fc0b3f7dc31 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
@@ -388,6 +388,26 @@ vreg_bob: bob {
};
};
+ {
+ status = "okay";
+};
+
+_i2c0 {
+ /* IMX800 @ 1a */
+};
+
+_i2c1 {
+ /* IMX858 @ 29 */
+};
+
+ {
+ status = "okay";
+};
+
+_i2c1 {
+ /* S5KJN1SQ03 @ 10 */
+};
+
{
/* Disable for now so simple-framebuffer continues working */
status = "disabled";
--
2.42.0
[PATCH 1/3] dt-bindings: i2c: qcom-cci: Document SC7280 compatible
Document the compatible for the CCI block found on SC7280 SoC. Signed-off-by: Luca Weiss --- Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml index 042d4dc636ee..158588236749 100644 --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-cci.yaml @@ -25,6 +25,7 @@ properties: - items: - enum: + - qcom,sc7280-cci - qcom,sdm845-cci - qcom,sm6350-cci - qcom,sm8250-cci -- 2.42.0
[PATCH 0/3] Add CCI support for SC7280
Add the dts nodes for the camera control interface found on the SC7280 SoC. And then enable the CCI nodes in the Fairphone 5 dts. Signed-off-by: Luca Weiss --- Luca Weiss (3): dt-bindings: i2c: qcom-cci: Document SC7280 compatible arm64: dts: qcom: sc7280: Add Camera Control Interface busses arm64: dts: qcom: qcm6490-fairphone-fp5: Enable CCI busses .../devicetree/bindings/i2c/qcom,i2c-cci.yaml | 1 + arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 20 +++ arch/arm64/boot/dts/qcom/sc7280.dtsi | 136 + 3 files changed, 157 insertions(+) --- base-commit: c858197a69efe69e1607f4854af42ec338e54e96 change-id: 20230929-sc7280-cci-4690ef8da107 Best regards, -- Luca Weiss
[PATCH] arm64: dts: qcom: sc7280: Add ports subnodes in usb/dp qmpphy node
Add the USB3+DP Combo QMP PHY port subnodes in the SC7280 SoC DTSI to
avoid duplication in the devices DTs.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 66f1eb83cca7..4e34d00e246b 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -3399,6 +3399,32 @@ usb_1_qmpphy: phy@88e8000 {
#clock-cells = <1>;
#phy-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_dp_qmpphy_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_dp_qmpphy_usb_ss_in: endpoint {
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb_dp_qmpphy_dp_in: endpoint {
+ };
+ };
+ };
};
usb_2: usb@8cf8800 {
---
base-commit: df964ce9ef9fea10cf131bf6bad8658fde7956f6
change-id: 20230929-sc7280-qmpphy-ports-20afd4212470
Best regards,
--
Luca Weiss
