On Wed, May 27, 2020 at 01:53:05PM +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 the series falls short of removing 1500 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, but the changes are done in a way > that shouldn't affect its behaviour. > > Note that the series builds up on RPi/Laurent's camera support series[1] > and can't yet be merged. We'd have to coordinate here. We could either > wait for the vc_sm_cma rework (if it's not going to take months and > months to finish), or factor out all the vc-sm-cma stuff, merge that into > the downstream kernel and take the rest of the series on top of > Laurent's mmal-vchiq changes. These look great, but due to the dependancy, I can't take them all. But I can take the first 10, so I did that, they are now queued up, thanks! greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
