On Mon, Mar 25, 2024 at 11:04 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > SCM calls that take memory buffers as arguments require that they be > page-aligned, physically continuous and non-cachable. The same > requirements apply to the buffer used to pass additional arguments to SCM > calls that take more than 4. > > To that end drivers typically use dma_alloc_coherent() to allocate memory > of suitable format which is slow and inefficient space-wise. > > SHM Bridge is a safety mechanism that - once enabled - will only allow > passing buffers to the TrustZone that have been explicitly marked as > shared. It improves the overall system safety with SCM calls and is > required by the upcoming scminvoke functionality. > > The end goal of this series is to enable SHM bridge support for those > architectures that support it but to that end we first need to unify the > way memory for SCM calls is allocated. This in itself is beneficial as > the current approach of using dma_alloc_coherent() in most places is quite > slow. > > First let's add a new TZ Memory allocator that allows users to create > dynamic memory pools of format suitable for sharing with the TrustZone. > Make it ready for implementing multiple build-time modes. > > Convert all relevant drivers to using it. Add separate pools for SCM core > and for qseecom. > > Finally add support for SHM bridge and make it the default mode of > operation with the generic allocator as fallback for the platforms that > don't support SHM bridge. > > Tested on db410c, RB5, sm8550-qrd. Previous iteration tested also on > sa8775p-ride and lenovo X13s (please do retest on those platforms if you > can). > The Subject should have been "firmware: qcom: implement support for and enable SHM bridge", sorry for the mixup. Bartosz
