CSI additions for testing

I found that even for testing i2c, it's not enough to have the clocks and power set up (have you seen the same)? I might be wrong here and this is only one idea. Then I looked at power consumption when the both cameras are switched off via the leds and it seems not to add to power consumption, as Angus suspected.

So I think we could add camera stuff but mainline drivers even if they don't work yet. This is enough to have i2c working and the test script could look something like this. You should read 0x00 and 0xde but that doesn't matter. As long as we can read from the devices:

#!/bin/bash
echo 1 | sudo tee /sys/devices/platform/dogwood_leds/leds/camera_pwr/brightness > /dev/null
echo 1 | sudo tee /sys/class/leds/camera_en/brightness > /dev/null
sleep 1
sudo i2cget -f -y 2 0x20 0x00
sudo i2cget -f -y 3 0x10 0x00

This contains the ugly Kconfig hack so that imx7-csi (staging driver) builds; adds the NXP mipi-csi2 driver and enables the devkit camera (that does not work here though). IMO it's still very interesting how that imx7-csi driver evolves upstream and whether the devkit camera starts working at some point without us changing much.

We might need to clean up this patchset a bit but then the driver development branch (more out of tree drivers) becomes a bit smaller when rebased against this.

In short: if we need a test now and i2c indeed doesn't work without csi descriptions/drivers (?), I'd like that approach because we'd have more incentive to fix these parts upstream sooner, like Kconfig and dts, that we probably need to do at some point anyways.