[RFC] Remaining drivers in RPI github tree/which drivers to submit

[Stefan Wahren]

Am 03.02.2017 um 00:13 schrieb Michael Zoran:
> On Thu, 2017-02-02 at 19:02 +0100, Stefan Wahren wrote:
>>> Michael Zoran <mzoran at crowfest.net> hat am 1. Februar 2017 um 05:27
>>> geschrieben:
>>>
>>>
>>> Here is a list of the remaining drivers that I know about in the
>>> downstream RPI github tree. I was wondering which ones are planned
>>> to
>>> be submitted and which ones need to stay on github.
>>>
>>> dwc_otg     - Host only USB driver(Probably not submittable)
>>> bcm2708_fb  - DMA accelerated simple video driver(Also not
>>> submittable)
>>> vc_cma      - Manages shared memory between GPU and ARM(Never
>>> worked
>>> well)
>>> vc_mem      - Allows for querying the GPU memory and memory mapping
>>> it
>>> vc_io       - User mode mailbox access
>>> vc_sm       - Support for the VC shared memory
>>> bcm2835-gpiomem - GPIO access from user mode
>>> bcm2835_smi_dev - Driver for secondary memory interface(Not sure
>>> what
>>> it does).
>>>
>>> vc_mem and vc_sm are already mentioned in the TODO list for
>>> vchiq/vc04_services to be submitted.
>>>
>>> What about the other drivers?
>> I think it's pretty pointless to push all downstream driver into
>> staging as long as there are only a few active kernel developer
>> taking care of them. IMHO we should concentrate on the unfinished
>> ones (e.g. thermal, sdhost, dwc2, vchiq, camera) first.
> I'm certainly willing to help with dwc2, vchiq, and the camera.  At
> least as much as help is desired.

I currently prepare and test OTG/Peripheral support for dwc2 on bcm2835
since the latest changes for 4.11.

I would be happy if you could verify with RPi 3 / ARM64 that nothing is
broken.

> I think vc_cma, vc_mem, and vc_sm need to go into staging IMHO.  That
> way all the vchiq based drivers would be in staging, and it would be
> possible to start stripping out parts of vchiq and simplifying it. 
> Which IMHO, is the biggest blocker of progress with vchiq.
>
> I was planning to submit vc_cma, vc_mem, and vc_sm tonight if nobody
> has any objections.

I unterstand your intention, but this also means that those drivers
needs to be maintained (in parallel to the downstream drivers).

Are their any users from kernel perspective of these drivers?

> I made a table the other day of which drivers are calling which
> functions.  It looks like several of the exported functions could be
> stripped right away.
>

Thanks