Hi Laurent,

On Mon, Dec 28, 2020 at 11:28:01PM +0200, Laurent Pinchart wrote:

Hello,

On Mon, Dec 28, 2020 at 08:35:20PM +0200, Sakari Ailus wrote:

quoted

Hi Ezequiel,

Thanks for the patch.

Likewise :-)

quoted

On Mon, Dec 28, 2020 at 03:05:11PM -0300, Ezequiel Garcia wrote:

quoted

There is currently little to none information available
about the reasons why a v4l2-async device hasn't
probed completely.

Inspired by the "devices_deferred" debugfs file,
add a file to list information about the subdevices
that are on waiting lists, for each notifier.

This is useful to debug v4l2-async subdevices
and notifiers, for instance when doing device bring-up.

For instance, a typical output would be:

$ cat /sys/kernel/debug/video4linux/waiting_subdevices
[fwnode] 1-003c
[fwnode] 20e0000.iomuxc-gpr:ipu1_csi1_mux
[fwnode] 20e0000.iomuxc-gpr:ipu1_csi0_mux

It's possible to provide some more information, detecting
the type of fwnode and printing of-specific or acpi-specific
details. For now, the implementation is kept simple.

The rest of the debug information we're effectively providing through
kernel messages on DEBUG level (pr_debug/dev_dbg). Could we do the same
here?

Would just printing the names of the pending sub-devices at notifier
register and async subdevice register time be sufficient? That way you'd
also be fine with just dmesg output if you're asking someone to provide you
information from another system.

I think debugfs would be better. It can show the current state of an
async notifier in a single place, which is easier to parse than
reconstructing it from kernel messages and implicit knowledge of the
code. I'd expect users to have an easier time debugging probe issues
with such centralized information.

If something goes wrong, you still need the kernel messages as the debugfs
file would only be able to tell what's waiting --- which is usually not
enough to fix it.

I don't mind adding a debugfs file for this if you think it's needed, but
it'd still be nice to have the information in the kernel messages (in terms
of which endpoints a notifier is still expecting). That could be a separate
patch, too.

-- 
Regards,

Sakari Ailus