On Tue, Nov 23, 2021 at 1:47 AM Laurent Pinchart
[off-list ref] wrote:

Hi Alexander,

On Tue, Nov 23, 2021 at 08:38:47AM +0100, Alexander Stein wrote:

quoted

Am Dienstag, dem 23.11.2021 um 02:15 +0200 schrieb Laurent Pinchart:

quoted

On Sun, Nov 21, 2021 at 09:07:26PM -0600, Adam Ford wrote:

quoted

On Sun, Nov 21, 2021 at 5:18 PM Laurent Pinchart wrote:

quoted

On Sat, Nov 06, 2021 at 10:54:26AM -0500, Adam Ford wrote:

quoted

The baseboard has support for a TDNext 5640 Camera which
uses an OV5640 connected to a 2-lane CSI2 interface.

With the CSI and mipi_csi2 drivers pointing to an OV5640 camera, the media
pipeline can be configured with the following:

    media-ctl --links "'ov5640 1-003c':0->'imx7-mipi-csis.0':0[1]"

The camera and various nodes in the pipeline can be configured for UYVY:
    media-ctl -v -V "'ov5640 1-003c':0 [fmt:UYVY8_1X16/640x480 field:none]"
    media-ctl -v -V "'csi':0 [fmt:UYVY8_1X16/640x480 field:none]"

Signed-off-by: Adam Ford <redacted>

As the ov5640 is on an add-on module, would a DT overlay be better ?

At least for the Beacon / LogicPD boards, I would prefer to avoid the
overlays.  We have an i.M6Q and an OMAP3 board with cameras enabled in
our development kit device trees.  If the cameras are not connected,
they just display a message that the cameras are not communicating and
move on.  I'm OK with that.

You know the board better than I do, so I won't push against this, but I
still think it may not lead to the best user experience, especially if a
user wanted to connect a different sensor to the development board.

I see the advantages of overlays compared to "stacked" .dts files. But
is there any general supported interface how to actually apply an overlay?
Documentation/devicetree/overlay-notes.rst
states of_overlay_fdt_apply() but there is only exactly one user in-
kernel (rcar-du). Is it expected that the bootloader like u-boot shall
apply the .dtbo files?

I believe the boot loader is expected to apply overlays nowadays, yes.
That's my personal workflow.

That is my understanding as well. I believe the support to apply dt
overlays within Linux (which the rpi kernel still uses) never got
merged due to race conditions so the focus was moved to bootloader.

I also have begun submitting some dt overlay files [1] [2] which I
will likely repost later this week removing the RFC.

My understanding is that these should be '.dtbo' files in the Linux
Makefile which are handled. My boards use the U-Boot bootloader and to
handle the dt overlays there you need to:
- set CONFIG_OF_LIBFDT_OVERLAY=y which gives you the 'fdt apply' command
- use 'fdt addr <addr> && fdt resize && fdt apply <loadaddr>' prior to
booting with booti
- Note that there is some support at the FIT level as well for
overlays if you need them applied to U-Boot's live dt (I don't for my
needs)

In my U-Boot environment I use scripts for loading the fdt and
applying the overlays. For example for booting kernel/dtb from network
I use:
boot_net setenv fsload tftpboot; run loadfdt && run apply_overlays &&
$fsload $kernel_addr_r venice/Image && booti $kernel_addr_r -
$fdt_addr_r
loadfdt if $fsload $fdt_addr_r $dir/$fdt_file1; then echo loaded
$fdt_file1; elif $fsload $fdt_addr_r $dir/$fdt_file2; then echo loaded
$fdt_file2; elif $fsload $fdt_addr_r $dir/$fdt_file3; then echo loaded
$fdt_file3; elif $fsload $fdt_addr_r $dir/$fdt_file4; then echo loaded
$fdt_file4; elif $fsload $fdt_addr_r $dir/$fdt_file5; then echo loaded
$fdt_file5; fi
apply_overlays fdt addr $fdt_addr_r && fdt resize && for i in
"$fdt_overlays"; do $fsload $loadaddr $dir/$i && fdt apply $loadaddr
&& echo applied $i...; done

Best regards,

Tim
[1] https://www.spinics.net/lists/arm-kernel/msg933447.html
[2] https://www.spinics.net/lists/arm-kernel/msg933638.html