[PATCH 6/6] drm/msm: add OCMEM driver

[Rob Clark]

On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov
<stanimir.varbanov at linaro.org> wrote:
> Hi Rob,
>
> Thanks for your work.
>
> On 09/29/2015 10:48 PM, Rob Clark wrote:
>> For now, since the GPU is the only upstream consumer, just stuff this
>> into drm/msm.  Eventually if we have other consumers, we'll have to
>
> As the video encoder/decoder driver (vidc) for apq8084 && msm8974 also
> use the ocmem for scratch buffers, it might be better to relocate the
> ocmem driver in drivers/soc/qcom from the beginning?

I wasn't really sure how soon vidc would support 8084/8974 (I assume
first target is 8916 which fortunately doesn't have ocmem), or if it
was mandatory or just power optimization..  but yes, the plan was to
move it somewhere else (not sure quite where, drivers/doc/qcom?)
sometime..  Preferably when someone who understands all the other
ocmem use-cases better could figure out what we really need to add to
the driver.

In downstream driver there is a lot of complexity that appears to be
in order to allow two clients to each allocate a portion of a macro
within a region (ie. aggregate_macro_state(), apply_macro_vote(),
etc), and I wanted to figure out if that is even a valid use-case
before trying to make ocmem something that could actually support
multiple clients.

There is also some complexity about ensuring that if clients aren't
split up on region boundaries, that you don't have one client in
region asking for wide-mode and other for narrow-mode..
(switch_region_mode()) but maybe we could handle that by just
allocating wide from bottom and narrow from top.  Also seems to be
some craziness for allowing one client to pre-empt/evict another.. a
dm engine, etc, etc..

All I know is gpu just statically allocates one big region aligned
chunk of ocmem, so I ignored the rest of the crazy (maybe or maybe not
hypothetical) use-cases for now...

BR,
-R

> I'm working on vidc driver upstream version so it will be nice to test
> ocmem driver from it, too.
>
>> split this out and make the allocation less hard coded.  But I'll punt
>> on that until I better understand the non-gpu uses-cases (and whether
>> the allocation *really* needs to be as complicated as it is in the
>> downstream driver).
>>
>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>> ---
>>  drivers/gpu/drm/msm/Makefile          |   3 +-
>>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  19 +-
>>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  19 +-
>>  drivers/gpu/drm/msm/msm_drv.c         |   2 +
>>  drivers/gpu/drm/msm/msm_gpu.h         |   3 +
>>  drivers/gpu/drm/msm/ocmem/ocmem.c     | 399 ++++++++++++++++++++++++++++++++++
>>  drivers/gpu/drm/msm/ocmem/ocmem.h     |  46 ++++
>>  7 files changed, 463 insertions(+), 28 deletions(-)
>>  create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.c
>>  create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.h
>>
>
> <snip>
>
> --
> regards,
> Stan