Message ID | 20200623164235.29566-1-nsaenzjulienne@suse.de (mailing list archive) |
---|---|
Headers | show |
Series | staging: vchiq: Getting rid of the vchi/vchiq split | expand |
On Tue, Jun 23, 2020 at 06:41:46PM +0200, Nicolas Saenz Julienne wrote: > vchi acts as a mid layer between vchiq and its kernel services, while > arguably providing little to no benefit: half of the functions exposed > are a 1:1 copy of vchiq's, and the rest provide some functionality which > can be easly integrated into vchiq without all the churn. Moreover it > has been found in the past as a blockage to further fixes in vchiq as > every change needed its vchi counterpart, if even possible. > > Hence this series, which merges all vchi functionality into vchiq and > provies a simpler and more concise API to services. > > I'm aware that kernel's vchi API tries to mimic its userspace > counterpart (or vice versa). Obviously this breaks the parity, but I > don't think it's a sane goal to have. There is little sense or gain from > it, and adds impossible constraints to upstreaming the driver. > > Overall this fall short of removing 1100 lines of code, which is pretty > neat on itself. > > So far it has been tested trough bcm2835-camera, audio and vchiq-test. I > can't do much about vc-sm-cma for now as it's only available downstream, > but I made sure not to break anything and will provide some patches for > the RPi devs to pick-up, so as to make their life easier. > > Note that in order to keep the divergence between the downstream and > upstream versions of this as small as possible I picked up some > mmal-vchiq patches that might not be absolutely necessary to the goal of > the series. I took the first 2 patches and will wait for the rest to be resent :) thanks, greg k-h