Enable logs in kernel driver

[aforey]

Hello,

I would like to work on customizing a screen driver. I have identified the driver file: /drivers/gpu/drm/panel/panel-sitronix-st7701.c. I want to enable logs in this file and view them.

I have tried many solutions found online, but none have been successful.

For example, I tried adding the linux/module.h and linux/kernel.h libraries to the panel-sitronix-st7701.c file, along with printk(KERN_INFO "some thing\n") logs in several places.
I enabled the following options:

• CONFIG_PRINTK=y
• CONFIG_DYNAMIC_DEBUG=y
• CONFIG_DEBUG_KERNEL=y

I also enabled the logs using the following command:

echo "module panel-sitronix-st7701 +p" > /sys/kernel/debug/dynamic_debug/control  

However, I don’t see anything new in dmesg.

Could you please guide me on how to enable logs in the driver and view them?

Best regards,

Arthur

[ToradexAI]

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

---

Hello Arthur,

Thank you for reaching out with your question about enabling logs in your kernel driver. It sounds like you’re on the right track with using printk for logging. Here are some steps to help ensure your logging works as expected:

1. Correct Use of printk:

   • Ensure your printk statements are correctly formatted, such as printk(KERN_INFO "Your message here\n");. The KERN_INFO level is suitable for informational messages.

2. Dynamic Debug Configuration:

   • You’ve correctly enabled dynamic debug for your module. Make sure the command echo "module panel-sitronix-st7701 +p" > /sys/kernel/debug/dynamic_debug/control is executed after the module is loaded.
   • Verify that CONFIG_DYNAMIC_DEBUG=y is set in your kernel configuration.

3. Kernel Boot Parameters:

   • Check that your kernel boot parameters do not suppress log levels. The loglevel parameter should be set to include KERN_INFO (e.g., loglevel=7).

4. Review dmesg Settings:

   • Ensure dmesg is configured to display the log level you are using. You can adjust the dmesg log level with dmesg -n 7 to show all messages.

5. Troubleshooting Tips:

   • If logs are still not visible, try using KERN_DEBUG instead of KERN_INFO for more verbosity.
   • Confirm that your changes to the driver file are compiled and loaded correctly. Adding a simple printk at the start of the driver’s initialization function can help verify that your changes are active.
   • Reboot the system after making changes to ensure all configurations are applied.

By following these steps, you should be able to see the logs from your driver in dmesg. If issues persist, double-check your kernel configuration and ensure the module is correctly loaded with the updated code.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Installing Display driver on Verdin iMX8M Mini

Hi guys, I’m trying to install a custom display driver for my Yocto Image Layer Build. The manufacturer provide me with the Makefile and the sources/headers files needed. I’m did follow the custom meta layer I added the MACHINE_EXTRA_RDEPENDS += “kernel-module-display” under the verdin-imx8mm.conf located on oe-core/layers/meta-toradex-nxp/conf/machine right below MACHINE_FEATURES: MACHINE_FEATURES += "3g bluetooth alsa ext2 pci screen touchscreen usbgadget usbhost vfat wifi" MACHINE_EXTRA_…

Why rpmsg_tty messages are logged into the journal log?

I have an application running on Torizon OS 6 which implements rpmsg communication between Torizon OS and M7. The communication itself works, but I noticed some CPU usage from systemd-journald process (~7%). I run journalctl command to see the logs and I see all the messages received from M7. I don’t see the messages sent by Torizon OS. Her is a snippet of the log Jul 19 13:12:35 verdin-imx8mp-15128331 kernel: rpmsg_tty_cb6f 63 6b 5c 22 2c 5c 22 74 79 70 65 5c 22 3a 5c ock\",\"type\":\ Jul…

MCP3428 Kernel driver.

[bruno.tx]

Hello @aforey,

The recommendations from the @ToradexAI are good, but I would also recommend that you take a look at the following resources that should help you debug this issue:

• Message logging with printk
• Dynamic debug documentation

As the log level for your messages is just KERN_INFO, it is possible that the messages are being hidden, so the printk documentation is especially relevant here.

Best Regards,
Bruno

[bruno.tx]

Hello @aforey,

Could you send me your image so I can check if there was a misconfiguration that may lead to the driver not being loaded?

If possible, please upload it to share.toradex.com and send an email with the link to support.eu@toradex.com.

Best Regards,
Bruno

[aforey]

Hello Bruno,

Thank you for checking in. I tried adding logs to the tc358768 driver following the instructions you provided, and it was a success!

However, I applied the same method to the st7701 driver, but I don’t see any logs in dmesg or when running the commands rmmod panel_sitronix_st7701 and modprobe panel_sitronix_st7701.

I have attached the source code of the driver I used. I am also sending you the link to the BSP I used.

Best regards,

Arthur

panel-sitronix-st7701.c (25.9 KB)

[bruno.tx]

Hello @aforey,

Thanks for the additional information.

I had a look at your image and was able to conclude the following:

• The correct device tree is configured on the device
• The custom module for the st7701 is being built and has your changes
• The device tree is correctly configured to load the st7701 driver
• The st7701 driver is being loaded by default on your image

The above leads me to believe that the overall configuration is correct.
What may be missing is some initialization step that is specific to this configuration.

I recommend that you enable the CONFIG_FTRACE config on your kernel to be able to use the ftrace functionality.
With that, you should be able to see more clearly which functions are being called when the kernel module is loaded.
For more information on how to use ftrace, please refer to the following page: Introduction to kernel tracing with ftrace - devkernel.io
The most useful part at least initially would be to use the function tracer.

Best Regards,
Bruno

[aforey]

Hello @bruno.tx ,

I have enabled the following kernel modules:

CONFIG_FTRACE=y  
CONFIG_FUNCTION_TRACER=y  
CONFIG_FUNCTION_GRAPH_TRACER=y  
CONFIG_DYNAMIC_FTRACE=y  

I added some traces in the ST7701 driver:

trace_printk("st7701: Test\n");

We do have the /sys/kernel/tracing/ directory, and we execute the following commands:

1. echo > trace
2. echo function > current_tracer
3. echo 1 > tracing_on
4. rmmod panel_sitronix_st7701
5. modprobe panel_sitronix_st7701
6. echo 0 > tracing_on

When I check the “trace” file, I don’t see the ST7701 log. However, I do see other logs.

I don’t see what else I can do…

Best regards,

Arthur

[aforey]

Hello @bruno.tx ,

Here is the modified driver file attached: panel-sitronix-st7701.c.

It uses two functions to initialize and remove it: st7701_dsi_probe and st7701_dsi_remove.

As you can see in the file, there is a log: trace_printk("st7701: Test\n");

panel-sitronix-st7701.c (25.8 KB)

However, I don’t even see the log from the st7701_dsi_probe function. Yet, the driver seems to be properly loaded when we check with lsmod.

I am also attaching the DTS files so you can verify the screen declaration.

k3-am62-verdin.dtsi (43.8 KB)
k3-am62-verdin-dev.dtsi (5.4 KB)
k3-am625-verdin-wifi-dev.dts (613 Bytes)
rfa6400e-awh-mnn.dtsi (804 Bytes)

I inserted logs into the tc358768 driver, and I can see them.

Best regards,
Arthur

[bruno.tx]

Hello @aforey,

Thanks for the additional information.

I will have a look at it and get back to you next week.

Best Regards,
Bruno

[aforey]

Hello @bruno.tx ,

Sorry to bother you again, have you had a chance to take a look?

Best regards,

Arthur

[bruno.tx]

Hello @aforey,

Sorry for the delay here.

I would recommend that you try to change the compatible string for your panel in your device tree to the following one:

compatible = "techstar,ts8550b";

Your device tree seems to be correct, but this change would be recommended in order to avoid any possible misconfigurations.

With that in place, please check if the status of the panel is expected in the image:

find /sys/firmware/ -name "*panel*" 
# In the directory you find verify that the status is either okay or not there
cat <directory>/status

Besides that it would be important to know if the init function is called.
For that, can you set the following ftrace filter?

echo "*st77*" > /sys/kernel/tracing/set_ftrace_filter

With this configuration, do you see the init function being called?

Best Regards,
Bruno

[aforey]

Hello @bruno.tx ,

I have made the string change and recompiled.
Here is what I get with the command:

find /sys/firmware/ -name "*panel*"
/sys/firmware/devicetree/base/panel
/sys/firmware/devicetree/base/__symbols__/mipi_panel_out
/sys/firmware/devicetree/base/__symbols__/panel_in

There is no status in the /sys/firmware/devicetree/base/panel directory:

ls /sys/firmware/devicetree/base/panel
IOVCC-supply  VCC-supply  compatible  dsi-lanes  name  pinctrl-0  pinctrl-names  port  reg  reset-gpios

It is not working; I don’t see the init being called. I have sent you a new BSP with the latest modifications.
Could you try on your side to get driver init logs with our BSP?

Best regards,

Arthur

[bruno.tx]

Hello @aforey,

Upon investigation of your image, the init function is being called, but the filtering I suggested did not cover it.

You can run the following commands to view the function calls resulting from modprobe:

rmmod panel_sitronix_st7701
echo nop > /sys/kernel/tracing/current_tracer
echo > /sys/kernel/tracing/set_ftrace_pid
echo > /sys/kernel/tracing/trace
echo function > /sys/kernel/tracing/current_tracer
echo 1 > /sys/kernel/tracing/options/func_restrict_task
echo cpuidle_* > /sys/kernel/tracing/set_ftrace_notrace
echo do_idle >> /sys/kernel/tracing/set_ftrace_notrace
echo cpufreq_* >> /sys/kernel/tracing/set_ftrace_notrace
echo 1 > /sys/kernel/tracing/events/sched/sched_process_exec/enable
echo 'comm=="modprobe" do_set_ftrace_pid common_pid' > /sys/kernel/tracing/events/sched/sched_process_exec/trigger
echo 1 > /sys/kernel/tracing/tracing_on
modprobe panel_sitronix_st7701
echo 0 > /sys/kernel/tracing/tracing_on
cat /sys/kernel/tracing/trace

This gives the following output on my setup:

# tracer: function
#
# entries-in-buffer/entries-written: 14/14   #P:4
#
#                                _-----=> irqs-off/BH-disabled
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| / _-=> migrate-disable
#                              |||| /     delay
#           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
#              | |         |   |||||     |         |
         sugov:0-130     [002] ...1.  5526.748778: __cpufreq_driver_target <-sugov_work
         sugov:0-130     [002] ...1.  5526.761245: __cpufreq_driver_target <-sugov_work
        modprobe-985     [001] .....  5526.763025: sched_process_exec: filename=/sbin/modprobe pid=985 old_pid=985
        modprobe-985     [001] ...1.  5526.769679: mipi_dsi_driver_register_full <-st7701_dsi_driver_init
        modprobe-985     [001] ...1.  5526.769688: driver_register <-mipi_dsi_driver_register_full
        modprobe-985     [001] ...1.  5526.769692: bus_add_driver <-driver_register
        modprobe-985     [001] ...1.  5526.769703: driver_attach <-bus_add_driver
        modprobe-985     [001] ...1.  5526.769708: module_add_driver <-bus_add_driver
        modprobe-985     [001] ...1.  5526.769733: driver_create_file <-bus_add_driver
        modprobe-985     [001] ...1.  5526.769736: driver_add_groups <-bus_add_driver
        modprobe-985     [001] ...1.  5526.769738: driver_create_file <-bus_add_driver
        modprobe-985     [001] ...1.  5526.769742: driver_create_file <-bus_add_driver
         sugov:0-130     [002] ...1.  5526.773764: __cpufreq_driver_target <-sugov_work
         sugov:0-130     [002] ...1.  5526.787795: __cpufreq_driver_target <-sugov_work

This indicates that the flow to load the driver is not necessarily reaching the custom code on your driver.
The following documentation may help with this topic, but we are already into more complex workings of how MIPI-DSI is used within the kernel: https://www.kernel.org/doc/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt

Best Regards,
Bruno

[aforey]

Hello Bruno,

Thank you for your response. I tried configuring it according to your parameters. I encountered two errors while executing the commands:

• echo 1 > /sys/kernel/tracing/options/func_restrict_task
  I can’t find the file.

The command:

find /sys/ -iname "func_restrict_task"

returns nothing.

• echo 'comm=="modprobe" do_set_ftrace_pid common_pid' > /sys/kernel/tracing/events/sched/sched_process_exec/trigger

I get the following error message:

echo: write error: Invalid argument

Here are the enabled modules:

CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_IRQSOFF_TRACER=y
CONFIG_PREEMPT_TRACER=y
CONFIG_SCHED_TRACER=y
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_FUNCTION_PROFILER=y
CONFIG_FTRACE_MCOUNT_RECORD=y
CONFIG_EVENT_TRACER=y

CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y

What’s wrong?

Best regards,
Arthur

[bruno.tx]

Hello @aforey,

I think my system may have had some additional ftrace parameters so that the previous configuration would work. Unfortunately, I could not replicate it again.
The following configuration should work regardless, but it is a less inclusive filter:

rmmod panel_sitronix_st7701
echo function > /sys/kernel/tracing/current_tracer
echo > /sys/kernel/tracing/trace
echo 1 > /sys/kernel/tracing/tracing_on
modprobe panel_sitronix_st7701
echo 0 > /sys/kernel/tracing/tracing_on
cat /sys/kernel/tracing/trace | grep -i dsi

Best Regards,
Bruno

[aforey]

Hello Bruno,

I executed the different commands. I got no output from the last one.

Best regards,

Arthur

[bruno.tx]

Hello @aforey,

Thanks for the update.
To replicate the same setup I have here, you could try this without the display connected.
I don’t think this helps much, as if the module does not even get to init when the display is connected something else may be wrong.

Further testing and debugging with your setup is needed to understand resolve this issue.

Best Regards,

[aforey]

Hello @bruno.tx,

We tested with and without a screen. It indeed never enters the init function.

Have you made any progress? Do you need anything else for testing and debugging?

Best regards,

Arthur

[bruno.tx]

Hello @aforey,

At this point testing on your setup is essential.
From the information I have, the image you generated seems to be mostly correct.
The image is loading the correct custom device tree, it has the custom driver, which also seems to be loaded, but not probed.

From my point of view, the Toradex BSP is providing what is should, which is a base for your customization.
What may be wrong is something related to your specific display combination, initialization sequence and/or connections.
Therefore, this problem falls into your hands to debug, as the software provided by Toradex is not the problem here.
There are many tools that can be used for debugging this type of kernel development which I mentioned in this thread.

If you don’t know how to proceed, we can recommend consultants or Toradex partners that are familiar with such integrations and would be able to do that for you and unblock you on this problem.
Please let me know if you would like us to give you a recommendation here.

Best Regards,
Bruno

[aforey]

Thank you, Bruno.

Could you please send us some recommendations?

Best regards,

Arthur