[RFC 0/2] BCM283x Camera Receiver driver

[Hans Verkuil]

On 06/15/17 14:29, Dave Stevenson wrote:
> On 15 June 2017 at 08:17, Hans Verkuil <hverkuil at xs4all.nl> wrote:
>> On 06/14/2017 11:03 PM, Dave Stevenson wrote:
>>>
>>> On 14 June 2017 at 18:38, Hans Verkuil <hverkuil at xs4all.nl> wrote:
>>>>
>>>> On 06/14/2017 06:29 PM, Dave Stevenson wrote:
>>>>>
>>>>>
>>>>> Hi Hans.
>>>>>
>>>>> On 14 June 2017 at 16:42, Hans Verkuil <hverkuil at xs4all.nl> wrote:
>>>>>>
>>>>>>
>>>>>> Hi Dave,
>>>>>>
>>>>>> How does this driver relate to this staging driver:
>>>>>>
>>>>>> drivers/staging/vc04_services/bcm2835-camera/
>>>>>>
>>>>>> It's not obvious to me.
>>>>>
>>>>>
>>>>>
>>>>> drivers/staging/vc04_services/bcm2835-camera/ is using the VideoCore
>>>>> firmware to control Unicam, ISP, and all the tuner algorithms. The ARM
>>>>> gets delivered fully processed buffers from the VideoCore side. The
>>>>> firmware only has drivers for the Omnivision OV5647 and Sony IMX219
>>>>> (and an unsupported one for the Toshiba TC358743).
>>>>>
>>>>> This driver is solely the Unicam block, reading the data in over
>>>>> CSI2/CCP2 from the sensor and writing it to memory. No ISP or control
>>>>> loops.
>>>>> Other than power management, this driver is running solely on the ARM
>>>>> with no involvement from the VideoCore firmware.
>>>>> The sensor driver is whatever suitable V4L2 subdevice driver you fancy
>>>>> attaching (as long as it supports CSI2, or eventually CCP2).
>>>>
>>>>
>>>>
>>>> What is the interaction between these two drivers? Can they co-exist?
>>>> I would expect them to be mutually exclusive.
>>>
>>>
>>> Mutually exclusive for the same Unicam instance, yes.
>>>
>>> There are two Unicam instances on all BCM283x chips and both are
>>> brought out on the Compute Modules. You could run bcm2835-unicam on
>>> one and bcm2835-camera on the other if you so wished.
>>> The firmware checks whether the csi nodes in the device tree are
>>> active, and won't touch them if they are.
>>
>>
>> It would be good if this explanation is mentioned both in the driver code
>> and (I think) in the bindings document of *both* drivers. This setup is
>> unusual, so some extra documentation isn't amiss.
> 
> OK, will add it to this driver for V2.
> The other driver cleanups are on my to-do list. Would you object
> horrendously if I deferred adding the explanation to that driver to
> when I'm doing those cleanups?

That's OK.

Just mention in the cover letter of the v2 patch series that you are planning
to do this.

	Hans