[v4,0/7] dma-buf: heaps: Add restricted heap

  The purpose of this patchset is for MediaTek secure video playback, and
also to enable other potential uses of this in the future. The 'restricted
dma-heap' will be used to allocate dma_buf objects that reference memory
in the secure world that is inaccessible/unmappable by the non-secure
(i.e. kernel/userspace) world.  That memory will be used by the secure/
trusted world to store secure information (i.e. decrypted media content).
The dma_bufs allocated from the kernel will be passed to V4L2 for video
decoding (as input and output). They will also be used by the drm
system for rendering of the content.

This patchset adds two MediaTek restricted heaps and they will be used in
v4l2[1] and drm[2].
1) restricted_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video
   Path). The buffer is reserved for the secure world after bootup and it
   is used for vcodec's ES/working buffer;
2) restricted_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is
   dynamically reserved for the secure world and will be got when we start
   playing secure videos. Once the security video playing is complete, the
   CMA will be released. This heap is used for the vcodec's frame buffer. 

[1] https://lore.kernel.org/linux-mediatek/20231206081538.17056-1-yunfei.dong@mediatek.com/
[2] https://lore.kernel.org/all/20231223182932.27683-1-jason-jh.lin@mediatek.com/

Change note:
v4: 1) Rename the heap name from "secure" to "restricted". suggested from
     Simon/Pekka. There are still several "secure" string in MTK file
     since we use ARM platform in which we call this "secure world"/
     "secure command".

v3: https://lore.kernel.org/linux-mediatek/20231212024607.3681-1-yong.wu@mediatek.com/
    1) Separate the secure heap to a common file(secure_heap.c) and mtk
     special file (secure_heap_mtk.c),  and put all the tee related code
     into our special file.
    2) About dt-binding, Add "mediatek," prefix since this is Mediatek TEE
     firmware definition.
    3) Remove the normal CMA heap which is a draft for qcom.
    Rebase on v6.7-rc1.

v2: https://lore.kernel.org/linux-mediatek/20231111111559.8218-1-yong.wu@mediatek.com/
    1) Move John's patches into the vcodec patchset since they use the new
       dma heap interface directly.
       https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong@mediatek.com/
    2) Reword the dt-binding description.
    3) Rename the heap name from mtk_svp to secure_mtk_cm.
       This means the current vcodec/DRM upstream code doesn't match this.
    4) Add a normal CMA heap. currently it should be a draft version.
    5) Regarding the UUID, I still use hard code, but put it in a private
    data which allow the others could set their own UUID. What's more, UUID
    is necessary for the session with TEE. If we don't have it, we can't
    communicate with the TEE, including the get_uuid interface, which tries
    to make uuid more generic, not working. If there is other way to make
    UUID more general, please free to tell me.
    
v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu@mediatek.com/
    Base on v6.6-rc1.

Yong Wu (7):
  dt-bindings: reserved-memory: Add mediatek,dynamic-restricted-region
  dma-buf: heaps: Initialize a restricted heap
  dma-buf: heaps: restricted_heap: Add private heap ops
  dma-buf: heaps: restricted_heap: Add dma_ops
  dma-buf: heaps: restricted_heap: Add MediaTek restricted heap and
    heap_init
  dma-buf: heaps: restricted_heap_mtk: Add TEE memory service call
  dma_buf: heaps: restricted_heap_mtk: Add a new CMA heap

 .../mediatek,dynamic-restricted-region.yaml   |  43 +++
 drivers/dma-buf/heaps/Kconfig                 |  16 +
 drivers/dma-buf/heaps/Makefile                |   4 +-
 drivers/dma-buf/heaps/restricted_heap.c       | 237 +++++++++++++
 drivers/dma-buf/heaps/restricted_heap.h       |  43 +++
 drivers/dma-buf/heaps/restricted_heap_mtk.c   | 322 ++++++++++++++++++
 6 files changed, 664 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-restricted-region.yaml
 create mode 100644 drivers/dma-buf/heaps/restricted_heap.c
 create mode 100644 drivers/dma-buf/heaps/restricted_heap.h
 create mode 100644 drivers/dma-buf/heaps/restricted_heap_mtk.c
  

On Fri, 12 Jan 2024 17:20:07 +0800
Yong Wu <yong.wu@mediatek.com> wrote:

> The purpose of this patchset is for MediaTek secure video playback, and
> also to enable other potential uses of this in the future. The 'restricted
> dma-heap' will be used to allocate dma_buf objects that reference memory
> in the secure world that is inaccessible/unmappable by the non-secure
> (i.e. kernel/userspace) world.  That memory will be used by the secure/
> trusted world to store secure information (i.e. decrypted media content).
> The dma_bufs allocated from the kernel will be passed to V4L2 for video
> decoding (as input and output). They will also be used by the drm
> system for rendering of the content.
> 
> This patchset adds two MediaTek restricted heaps and they will be used in
> v4l2[1] and drm[2].
> 1) restricted_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video
>    Path). The buffer is reserved for the secure world after bootup and it
>    is used for vcodec's ES/working buffer;
> 2) restricted_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is
>    dynamically reserved for the secure world and will be got when we start
>    playing secure videos. Once the security video playing is complete, the
>    CMA will be released. This heap is used for the vcodec's frame buffer. 
> 
> [1] https://lore.kernel.org/linux-mediatek/20231206081538.17056-1-yunfei.dong@mediatek.com/
> [2] https://lore.kernel.org/all/20231223182932.27683-1-jason-jh.lin@mediatek.com/
> 
> Change note:
> v4: 1) Rename the heap name from "secure" to "restricted". suggested from
>      Simon/Pekka. There are still several "secure" string in MTK file
>      since we use ARM platform in which we call this "secure world"/
>      "secure command".

Hi,

I am really happy about this name change, thank you.

It is unfortunate that ARM specifications use the word "secure", but so
be it. When referring to specs, it's good to use the spec wording.

In everything that is not a direct reference to some spec though it
would be nice to use the "restricted" terminology if possible. I
presume there are other vendors who use words other than what ARM uses
for similar concepts. A common vocabulary would be nice.


Thanks,
pq

> v3: https://lore.kernel.org/linux-mediatek/20231212024607.3681-1-yong.wu@mediatek.com/
>     1) Separate the secure heap to a common file(secure_heap.c) and mtk
>      special file (secure_heap_mtk.c),  and put all the tee related code
>      into our special file.
>     2) About dt-binding, Add "mediatek," prefix since this is Mediatek TEE
>      firmware definition.
>     3) Remove the normal CMA heap which is a draft for qcom.
>     Rebase on v6.7-rc1.
> 
> v2: https://lore.kernel.org/linux-mediatek/20231111111559.8218-1-yong.wu@mediatek.com/
>     1) Move John's patches into the vcodec patchset since they use the new
>        dma heap interface directly.
>        https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong@mediatek.com/
>     2) Reword the dt-binding description.
>     3) Rename the heap name from mtk_svp to secure_mtk_cm.
>        This means the current vcodec/DRM upstream code doesn't match this.
>     4) Add a normal CMA heap. currently it should be a draft version.
>     5) Regarding the UUID, I still use hard code, but put it in a private
>     data which allow the others could set their own UUID. What's more, UUID
>     is necessary for the session with TEE. If we don't have it, we can't
>     communicate with the TEE, including the get_uuid interface, which tries
>     to make uuid more generic, not working. If there is other way to make
>     UUID more general, please free to tell me.
>     
> v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu@mediatek.com/
>     Base on v6.6-rc1.
> 
> Yong Wu (7):
>   dt-bindings: reserved-memory: Add mediatek,dynamic-restricted-region
>   dma-buf: heaps: Initialize a restricted heap
>   dma-buf: heaps: restricted_heap: Add private heap ops
>   dma-buf: heaps: restricted_heap: Add dma_ops
>   dma-buf: heaps: restricted_heap: Add MediaTek restricted heap and
>     heap_init
>   dma-buf: heaps: restricted_heap_mtk: Add TEE memory service call
>   dma_buf: heaps: restricted_heap_mtk: Add a new CMA heap
> 
>  .../mediatek,dynamic-restricted-region.yaml   |  43 +++
>  drivers/dma-buf/heaps/Kconfig                 |  16 +
>  drivers/dma-buf/heaps/Makefile                |   4 +-
>  drivers/dma-buf/heaps/restricted_heap.c       | 237 +++++++++++++
>  drivers/dma-buf/heaps/restricted_heap.h       |  43 +++
>  drivers/dma-buf/heaps/restricted_heap_mtk.c   | 322 ++++++++++++++++++
>  6 files changed, 664 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-restricted-region.yaml
>  create mode 100644 drivers/dma-buf/heaps/restricted_heap.c
>  create mode 100644 drivers/dma-buf/heaps/restricted_heap.h
>  create mode 100644 drivers/dma-buf/heaps/restricted_heap_mtk.c
>