[PATCH 00/50] staging: vchiq: Getting rid of the vchi/vchiq split

[Greg KH]

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