mostly

Thank you! That's the part that i was missing. 
Now i'm able to run ov5640 on OrangePiPcPlus with kernel 5.4.45. My dts: https://pastebin.com/gdQnnrxQ
/dev/video1 appears after reboot (no manual modprobe ov5640 needed). ov5640 for some reason does not leave any footprint in dmesg.
I've kept compatible = "allwinner,sun6i-a31-i2c" in i2c2@1c2b400 to be able to check chip id by i2cdetect. And nothing was working without compatible = "allwinner,sun8i-h3-csi" and other stuff inside csi@1cb0000.
 
Would be nice to pull the solution into official build (maybe as overlay)  . Ov5640 module is one of very few official orangepi accessories
 
 
according to https://linux-sunxi.org/CSI
media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY/1920x1080]' 1920x1080 and 1280x760 are working well for me
fswebcam -d /dev/video1 -r 1920x1080 -D 3 --jpeg 100 /mnt/sd/aaa.jpg --- Opening /dev/video1... Trying source module v4l2... /dev/video1 opened. No input was specified, using the first. Delaying 3 seconds. --- Capturing frame... Captured frame in 0.00 seconds. --- Processing captured image... Setting output format to JPEG, quality 100 Writing JPEG image to '/mnt/sd/aaa.jpg'.  

Thank you! That's the part that i was missing. 
Now i'm able to run ov5640 on OrangePiPcPlus with kernel 5.4.45. My dts: https://pastebin.com/gdQnnrxQ
/dev/video1 appears after reboot (no manual modprobe ov5640 needed). ov5640 for some reason does not leave any footprint in dmesg.
I've kept compatible = "allwinner,sun6i-a31-i2c" in i2c2@1c2b400 to be able to check chip id by i2cdetect. And nothing was working without compatible = "allwinner,sun8i-h3-csi" and other stuff inside csi@1cb0000.
 
Would be nice to pull the solution into official build (maybe as overlay)  . Ov5640 module is one of very few official orangepi accessories
 
 
according to https://linux-sunxi.org/CSI
media-ctl --device /dev/media1 --set-v4l2 '"ov5640 1-003c":0[fmt:UYVY/1920x1080]' 1920x1080 and 1280x760 are working well for me
fswebcam -d /dev/video1 -r 1920x1080 -D 3 --jpeg 100 /mnt/sd/aaa.jpg --- Opening /dev/video1... Trying source module v4l2... /dev/video1 opened. No input was specified, using the first. Delaying 3 seconds. --- Capturing frame... Captured frame in 0.00 seconds. --- Processing captured image... Setting output format to JPEG, quality 100 Writing JPEG image to '/mnt/sd/aaa.jpg'.  

@MikePooh, I think there's still some schematic-reading involved at the moment, if you're willing to do that though it should be do-able. I don't know anything about other boards yet so this is the process followed. I think for "it just works" you'll need to wait a bit more. I'm assuming a lot here, e.g. active high and fixed-voltage gpio-switched regulators, so there is risk in following this.

The first step is getting i2c working, the driver won't be able to do anything until you can communicate with the camera. I'll use the h5 in my Orange Pi Zero Plus2 as an example but I believe the process should be identical for h3 boards. Looking at the schematic (https://linux-sunxi.org/images/f/f6/ORANGE_PI-ZERO-PLUS2_V1_0.pdf), on page 9 is the csi connector. We want AFCC_EN, CSI_EN and CSI-PWR-EN to be '1' to power the camera. They might be named differently on different boards, but generally you're looking for the ones that aren't connected to pins (on page 6,  chip U1D) with a CSI_* function (e.g. PE9/CSI_D5/TS_D5). I'm looking for AFCC_EN and CSI-PWR-EN which link to page 6. So AFCC_EN comes from pin PA7/SIM_CLK/PA_EINT7 and CSI-PWR-EN from PA8/SIM_DATA/PA_EINT8. We need to remember those PXX numbers.
 
rreignier said their camera was on the i2c1 bus, so we need to confirm that too. Following CSI-SCK and CSI-SDA from page 9 to page 6 reveals the i2c interface. CSI-SCK for me connects to "PE12/CSI_SCK/TWI2_SCK" and CSI-SDA to "PE13/CSI_SDA/TWI2_SDA". Maybe someone can confirm, but I think TWIx_SDA equals I2Cx. You can test by enabling the i2c bus overlays one after the other and running i2cdetect while measuring with a multimeter on low range (200mv) A/C voltage between ground and the SCK pin on the camera connector - the correct bus will generate a voltage for a short while. We need to remember that bus number.

Note the reset-gpios and powerdown-gpios the same way.

Next is the change to the device tree. In Armbian checkout the linux source  with "apt install linux-source-<kernel version>-current-sunxi" (or linux-source-<kernel version>-current-sunxi64 for h5) which will leave you with a tar in /usr/src of your kernel source. extract it (do it in a new folder or it will trash your current one) and then copy your kernel config in (cp /boot/config-* ./.config). Edit your .dts (./arch/arm/boot/dts/ for h3, ./arch/arm64/boot/dts/allwinner/ for h5) in line with my previous comment, swapping in your values for regulators, i2c bus and reset/powerdown. for a quick bodge, which pin goes in which regulator doesn't actually matter - my change just forced them all on anyway. As lex said, there's supposed to be an order, my change doesn't respect that order but it has worked so far. Then run "make dtbs" from the top level of the kernel source. That should produce a .dtb file in the same folder as the .dts.

backup your current dtb and copy the new one to /boot/dtb/allwinner/*.dtb (that's the h5 path, not sure of the h3 path sorry, might be /boot/dtb/). I think you can alternatively specify this as fdtfile in the armbianEnv.txt. The armbianEnv.txt way will probably survive an update better.

Finally, add a line to /etc/modules that says ov5640. Reboot and you might be good to go. If you don't have a /dev/video0 device we'll have to debug.

Obviously if I've got something wrong feel free to chip in.

Has anyone had success with resolutions other than 640x480? The driver seems to have some code for it, but I haven't gotten anything to work.

I was not able to change resolution on mainline, but thanks a lot for pointing to the right patch.
The patch still has wrong parameters for 1024x768. After changing them to appropriate values (according to timings calculator), green box disappeared and hdmi sound becаme perfectly clear.
Pull request #1013